from:"Jimmy Mcarthur"

Re: [openstack-dev] Project Navigator Updates - Feedback Request

2017-04-24 Thread Jimmy McArthur


Dmitry,

It's a good question. Right now, not very well. For this update, we 
worked to get as many projects as we could updated within the existing 
template. Post-Boston, we will revisit projects that have multiple API 
services (or otherwise don't quite fit into the project template) to see 
how we can better represent them within the navigator.  If you have any 
thoughts on the matter, please feel free to send them our way.


Thank you!
Jimmy


Dmitry Tantsur 
April 24, 2017 at 9:29 AM
Quick question, sorry for top-posting. How does it represent projects 
that have several API services, like Baremetal or Telemetry?





__ 


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][ptls][tc] help needed filling out project-navigator data

2017-04-21 Thread Jimmy McArthur

Just wanted to say thank you to the projects that have already updated. The 
information you provided has already helped make things more accurate on the 
project nav. 

For other projects, please get this info in the repo as soon as you can. When 
we release the new version the Project Navigator, we would like for it to 
contain correct data for all projects. 

Thank you for your assistance!!
Jimmy




> On Apr 21, 2017, at 7:19 AM, Monty Taylor <mord...@inaugust.com> wrote:
> 
>> On 04/20/2017 05:03 AM, Andrey Kurilin wrote:
>> Hi folks!
>> 
>> Does it possible to store history of the project without alignment to
>> OpenStack releases?
> 
> Not at the moment - the view is based on OpenStack releases.
> 
> That said - it's a git repo, there's no reason we couldn't store some 
> additional info that the navigator doesn't (yet) need. ... Could you describe 
> a little more what you want to additionally store? Maybe we can come up with 
> something for it...
> 
>> 2017-04-19 17:54 GMT+03:00 Jimmy McArthur <ji...@openstack.org
>> <mailto:ji...@openstack.org>>:
>> 
>>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 <mailto:tenob...@redhat.com>
>>>April 19, 2017 at 9:48 AM
>>>Hi Monty,
>>> 
>>>quick question, how far into past releases should we go?
>>> 
>>>Thanks,
>>> 
>>>--
>>> 
>>>TELLES NOBREGA
>>> 
>>>SOFTWARE ENGINEER
>>> 
>>>Red Hat I <https://www.redhat.com/>
>>> 
>>>tenob...@redhat.com <mailto:tenob...@redhat.com>
>>> 
>>><https://red.ht/sig>
>>>TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>>> 
>>>
>>> __
>>>OpenStack Development Mailing List (not for usage questions)
>>>Unsubscribe:
>>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>><mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>><http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>>Monty Taylor <mailto:mord...@inaugust.com>
>>>April 18, 2017 at 3:03 PM
>>>Hey everybody!
>>> 
>>>The Foundation is rolling out a new version of the Project
>>>Navigator. One of the things it contains is a section that shows
>>>API versions available for each project for each release. They
>>>asked the TC's help in providing that data, so we spun up a new
>>>repository:
>>> 
>>>  http://git.openstack.org/cgit/openstack/project-navigator-data
>>><http://git.openstack.org/cgit/openstack/project-navigator-data>
>>> 
>>>that the Project Navigator will consume.
>>> 
>>>We need your help!
>>> 
>>>The repo contains a file for each project for each release with
>>>CURRENT/SUPPORTED/DEPRECATED major versions and also microversion
>>>ranges if they exist. The data is pretty much exactly what
>>>everyone already produces in their version discovery documents -
>>>although it's normalized into the format described by the API-WG:
>>> 
>>> 
>>>
>>> https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html#version-discovery
>>>
>>> <https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html#version-discovery>
>>> 
>>> 
>>>What would be really helpful is if someone from each project could
>>>go make a patch to the repo adding the historical (and currently)
>>>info for your project. We'll come up with a process for
>>>maintaining it over time - but for now just crowdsourcing the data
>>>seems like the best way.
>>> 
>>>The README file explains the format, and there is data from a few
>>>of the projects for Newton.
>>> 
>>>It would be great to include an entry for every release - which
>>>for many projects will just be the same content copied a bunch of
>>>times back to the first r

Re: [openstack-dev] [Cinder][Nova] Scheduling issue for the Summit

2017-04-20 Thread Jimmy McArthur


Sean,

Can you send this request into speakersupp...@openstack.org and we'll 
see if we can move it around.


Thanks,
Jimmy


Sean McGinnis 
April 20, 2017 at 9:55 AM
Unfortunately I am way late at noticing this, but bringing it up in case
there's anything that can still be done about it.

Tuesday the 9th, from 11:15am-11:55am, is going to be a challenge for me.
The Track Chairs Recap, Using Cinder for Nova Ephemeral Storage, and the
Cinder - Project Onboarding sessions are all at this slot.

While onboarding is something I feel is really imortant, out of these as
it is now I think I would have to go with the Cinder Nova discussion. But
that really would be a shame to have to miss that. I also would really
like to be part of the Track Chair discussion, but if I have to rank
these, that one will have to be last. I'm guessing there's really no
good time for that session that is not going to cause a conflict for
somebody.

So my question for the scheduling powers that be - is there any chance
we can move either the Cinder Onboarding or the Cinder-Nova sessions?

Thanks,
Sean (smcginnis)


__
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][ptls][tc] help needed filling out project-navigator data

2017-04-19 Thread Jimmy McArthur

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 far into past releases should we go?

Thanks,

TELLESNOBREGA

SOFTWARE ENGINEER

Red HatI

tenob...@redhat.com

TRIED. TESTED. TRUSTED.

__
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
Monty Taylor
April 18, 2017 at 3:03 PM
Hey everybody!

The Foundation is rolling out a new version of the Project Navigator.
One of the things it contains is a section that shows API versions
available for each project for each release. They asked the TC's help
in providing that data, so we spun up a new repository:

http://git.openstack.org/cgit/openstack/project-navigator-data

that the Project Navigator will consume.

We need your help!

The repo contains a file for each project for each release with
CURRENT/SUPPORTED/DEPRECATED major versions and also microversion
ranges if they exist. The data is pretty much exactly what everyone
already produces in their version discovery documents - although it's
normalized into the format described by the API-WG:

https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html#version-discovery

What would be really helpful is if someone from each project could go
make a patch to the repo adding the historical (and currently) info
for your project. We'll come up with a process for maintaining it over
time - but for now just crowdsourcing the data seems like the best way.

The README file explains the format, and there is data from a few of
the projects for Newton.

It would be great to include an entry for every release - which for
many projects will just be the same content copied a bunch of times
back to the first release the project was part of OpenStack.

This is only needed for service projects (something that registers in
the keystone catalog) and is only needed for 'main' APIs (like, it is
not needed, for now, to put in things like Placement)

If y'all could help - it would be super great!

Thanks!
Monty

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] [tc] version document for project navigator

2017-04-18 Thread Jimmy McArthur


Thank you, sir! :)


Monty Taylor <mailto:mord...@inaugust.com>
April 18, 2017 at 3:38 PM
I just sent out the email requesting folks send in patches. Maybe 
we'll get a flood of them now ...





__ 


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
Jimmy McArthur <mailto:ji...@openstack.org>
April 18, 2017 at 8:46 AM
All, we have modified our ingest tasks to look for this new data. Can 
we get an ETA on when to expect updates from the majority of projects? 
Right now, there isn't too much to test with.


Cheers,
Jimmy


__
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
Thierry Carrez <mailto:thie...@openstack.org>
April 14, 2017 at 3:21 AM

OK approved.

Doug Hellmann <mailto:d...@doughellmann.com>
April 13, 2017 at 11:43 AM

+1

The multi-file format was what the navigator team wanted, and there's
plenty of support for it among other reviewers. Let's move this forward.

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
Thierry Carrez <mailto:thie...@openstack.org>
April 13, 2017 at 11:03 AM

Do we really need the TC approval on this ? It's not a formal governance
change or anything.

Whoever has rights on that repo could approve it now and ask for
forgiveness later :)



__
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] [tc] version document for project navigator

2017-04-18 Thread Jimmy McArthur

All, we have modified our ingest tasks to look for this new data. Can we 
get an ETA on when to expect updates from the majority of projects? 
Right now, there isn't too much to test with.


Cheers,
Jimmy


Thierry Carrez <mailto:thie...@openstack.org>
April 14, 2017 at 3:21 AM

OK approved.

Doug Hellmann <mailto:d...@doughellmann.com>
April 13, 2017 at 11:43 AM

+1

The multi-file format was what the navigator team wanted, and there's
plenty of support for it among other reviewers. Let's move this forward.

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
Thierry Carrez <mailto:thie...@openstack.org>
April 13, 2017 at 11:03 AM

Do we really need the TC approval on this ? It's not a formal governance
change or anything.

Whoever has rights on that repo could approve it now and ask for
forgiveness later :)

Monty Taylor <mailto:mord...@inaugust.com>
April 13, 2017 at 10:25 AM
On 04/13/2017 08:28 AM, Jimmy McArthur wrote:

Just checking on the progress of this. :)


Unfortunately a good portion of the TC was away this week at the 
leadership training so getting a final ok on it was a bit stalled. 
It's seeming like the multi-file version is the one most people like 
though, so I'm mostly expecting that to be what we end up with. We 
should be able to get final approval by Tuesday, and then can work on 
getting all of the project info filled in.



Monty Taylor <mailto:mord...@inaugust.com>
April 7, 2017 at 7:05 AM


There is a new repo now:

http://git.openstack.org/cgit/openstack/project-navigator-data

I have pushed up two different patches with two different approaches:

https://review.openstack.org/#/c/454691
https://review.openstack.org/#/c/454688

One is a single file per release. The other is a file per service per
release.

Benefits of the single-file are that it's a single file to pull and
parse.

Benefits of the multi-file approach are that projects can submit
documents for themselves as patches without fear of merge conflicts,
and that the format is actually _identical_ to the format for version
discovery from the API-WG, minus the links section.

I think I prefer the multi-file approach, but would be happy either 
way.


__ 



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
Jimmy McArthur <mailto:ji...@openstack.org>
April 6, 2017 at 3:51 PM
Cool. Thanks Monty!


__ 


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
Monty Taylor <mailto:mord...@inaugust.com>
April 6, 2017 at 3:21 PM
On 04/06/2017 11:58 AM, Jimmy McArthur wrote:
Assuming this format is accepted, do you all have any sense of when 
this

data will be complete for all projects?


Hopefully "soon" :)

Honestly, it's not terribly difficult data to produce, so once we're
happy with it and where it goes, crowdsourcing filling it all in
should go quickly.


Jimmy McArthur <mailto:ji...@openstack.org>
April 5, 2017 at 8:59 AM
FWIW, from my perspective on the Project Navigator side, this format
works great. We can actually derive the age of the project from this
information as well by identifying the first release that has API 
data
for a particular project. I'm indifferent about where it lives, so 
I'd

defer to you all to determine the best spot.

I really appreciate you all putting this together!

Jimmy


__ 



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
Thierry Carrez <mailto:thie...@openstack.org>
April 5, 2017 at 5:28 AM

Somehow missed this thread, so will repost here comments I made
elsewhere:

This looks good, but I would rather not overload the releases
repository. My personal preference (which was also expressed by
Doug in the TC meeting) would be to set this information up in a
"project-navigator" git repo that we would reuse for any 
information we

need to collect from projects for accurate display on the project
navigator. If the data is not maintained anywhere else (or easily
derivable from existing data), we would use that repository to 
collect

it from projects.

That way there is a clear place to go to to propose fixes to the
project
navigat

Re: [openstack-dev] [tc] version document for project navigator

2017-04-13 Thread Jimmy McArthur


Just checking on the progress of this. :)


Monty Taylor <mailto:mord...@inaugust.com>
April 7, 2017 at 7:05 AM


There is a new repo now:

http://git.openstack.org/cgit/openstack/project-navigator-data

I have pushed up two different patches with two different approaches:

https://review.openstack.org/#/c/454691
https://review.openstack.org/#/c/454688

One is a single file per release. The other is a file per service per 
release.


Benefits of the single-file are that it's a single file to pull and 
parse.


Benefits of the multi-file approach are that projects can submit 
documents for themselves as patches without fear of merge conflicts, 
and that the format is actually _identical_ to the format for version 
discovery from the API-WG, minus the links section.


I think I prefer the multi-file approach, but would be happy either way.

__ 


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
Jimmy McArthur <mailto:ji...@openstack.org>
April 6, 2017 at 3:51 PM
Cool. Thanks Monty!


__
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
Monty Taylor <mailto:mord...@inaugust.com>
April 6, 2017 at 3:21 PM
On 04/06/2017 11:58 AM, Jimmy McArthur wrote:

Assuming this format is accepted, do you all have any sense of when this
data will be complete for all projects?


Hopefully "soon" :)

Honestly, it's not terribly difficult data to produce, so once we're 
happy with it and where it goes, crowdsourcing filling it all in 
should go quickly.



Jimmy McArthur <mailto:ji...@openstack.org>
April 5, 2017 at 8:59 AM
FWIW, from my perspective on the Project Navigator side, this format
works great. We can actually derive the age of the project from this
information as well by identifying the first release that has API data
for a particular project. I'm indifferent about where it lives, so I'd
defer to you all to determine the best spot.

I really appreciate you all putting this together!

Jimmy


__ 


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
Thierry Carrez <mailto:thie...@openstack.org>
April 5, 2017 at 5:28 AM

Somehow missed this thread, so will repost here comments I made 
elsewhere:


This looks good, but I would rather not overload the releases
repository. My personal preference (which was also expressed by
Doug in the TC meeting) would be to set this information up in a
"project-navigator" git repo that we would reuse for any information we
need to collect from projects for accurate display on the project
navigator. If the data is not maintained anywhere else (or easily
derivable from existing data), we would use that repository to collect
it from projects.

That way there is a clear place to go to to propose fixes to the 
project

navigator data. Not knowing how to fix that data is a common complaint,
so if we can point people to a git repo (and redirect people from there
to the places where other bits of information happen to live) that 
would

be great.

Monty Taylor <mailto:mord...@inaugust.com>
April 4, 2017 at 5:47 PM
Hey all,

As per our discussion in today's TC meeting, I have made a document
format for reporting versions to the project navigator. I stuck it in
the releases repo:

  https://review.openstack.org/453361

Because there was already per-release information there, and the
governance repo did not have that structure.

I've included pseudo-code and a human explanation of how to get from a
service's version discovery document to the data in this document, but
also how it can be maintained- which is likely to be easier by hand
than by automation - but who knows, maybe we decide we want to make a
devstack job for each service that runs on tag events that submits a
patch to the releases repo. That sounds like WAY more work than once a
cycle someone adding a few lines of json to a repo - but *shrug*.

Basing it on the version discovery docs show a few things:

* "As a user, I want to consume an OpenStack Service's Discovery
Document" is a thing people might want to do and want to do
consistently across services.

* We're not that far off from being able to do that today.

* Still, like we are in many places, we're randomly different in a few
minor ways that do not actually matter but make life har

Re: [openstack-dev] [tc] version document for project navigator

2017-04-06 Thread Jimmy McArthur


Cool. Thanks Monty!


Monty Taylor <mailto:mord...@inaugust.com>
April 6, 2017 at 3:21 PM
On 04/06/2017 11:58 AM, Jimmy McArthur wrote:

Assuming this format is accepted, do you all have any sense of when this
data will be complete for all projects?


Hopefully "soon" :)

Honestly, it's not terribly difficult data to produce, so once we're 
happy with it and where it goes, crowdsourcing filling it all in 
should go quickly.



Jimmy McArthur <mailto:ji...@openstack.org>
April 5, 2017 at 8:59 AM
FWIW, from my perspective on the Project Navigator side, this format
works great. We can actually derive the age of the project from this
information as well by identifying the first release that has API data
for a particular project. I'm indifferent about where it lives, so I'd
defer to you all to determine the best spot.

I really appreciate you all putting this together!

Jimmy


__ 


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
Thierry Carrez <mailto:thie...@openstack.org>
April 5, 2017 at 5:28 AM

Somehow missed this thread, so will repost here comments I made 
elsewhere:


This looks good, but I would rather not overload the releases
repository. My personal preference (which was also expressed by
Doug in the TC meeting) would be to set this information up in a
"project-navigator" git repo that we would reuse for any information we
need to collect from projects for accurate display on the project
navigator. If the data is not maintained anywhere else (or easily
derivable from existing data), we would use that repository to collect
it from projects.

That way there is a clear place to go to to propose fixes to the 
project

navigator data. Not knowing how to fix that data is a common complaint,
so if we can point people to a git repo (and redirect people from there
to the places where other bits of information happen to live) that 
would

be great.

Monty Taylor <mailto:mord...@inaugust.com>
April 4, 2017 at 5:47 PM
Hey all,

As per our discussion in today's TC meeting, I have made a document
format for reporting versions to the project navigator. I stuck it in
the releases repo:

  https://review.openstack.org/453361

Because there was already per-release information there, and the
governance repo did not have that structure.

I've included pseudo-code and a human explanation of how to get from a
service's version discovery document to the data in this document, but
also how it can be maintained- which is likely to be easier by hand
than by automation - but who knows, maybe we decide we want to make a
devstack job for each service that runs on tag events that submits a
patch to the releases repo. That sounds like WAY more work than once a
cycle someone adding a few lines of json to a repo - but *shrug*.

Basing it on the version discovery docs show a few things:

* "As a user, I want to consume an OpenStack Service's Discovery
Document" is a thing people might want to do and want to do
consistently across services.

* We're not that far off from being able to do that today.

* Still, like we are in many places, we're randomly different in a few
minor ways that do not actually matter but make life harder for our
users.

Thoughts and feedback more than welcome!
Monty

__ 



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
Jimmy McArthur <mailto:ji...@openstack.org>
April 6, 2017 at 11:58 AM
Assuming this format is accepted, do you all have any sense of when 
this data will be complete for all projects?



__
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
Jimmy McArthur <mailto:ji...@openstack.org>
April 5, 2017 at 8:59 AM
FWIW, from my perspective on the Project Navigator side, this format 
works great. We can act

Re: [openstack-dev] [tc] version document for project navigator

2017-04-06 Thread Jimmy McArthur

Assuming this format is accepted, do you all have any sense of when this 
data will be complete for all projects?



Jimmy McArthur <mailto:ji...@openstack.org>
April 5, 2017 at 8:59 AM
FWIW, from my perspective on the Project Navigator side, this format 
works great. We can actually derive the age of the project from this 
information as well by identifying the first release that has API data 
for a particular project. I'm indifferent about where it lives, so I'd 
defer to you all to determine the best spot.


I really appreciate you all putting this together!

Jimmy


__
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
Thierry Carrez <mailto:thie...@openstack.org>
April 5, 2017 at 5:28 AM

Somehow missed this thread, so will repost here comments I made elsewhere:

This looks good, but I would rather not overload the releases
repository. My personal preference (which was also expressed by
Doug in the TC meeting) would be to set this information up in a
"project-navigator" git repo that we would reuse for any information we
need to collect from projects for accurate display on the project
navigator. If the data is not maintained anywhere else (or easily
derivable from existing data), we would use that repository to collect
it from projects.

That way there is a clear place to go to to propose fixes to the project
navigator data. Not knowing how to fix that data is a common complaint,
so if we can point people to a git repo (and redirect people from there
to the places where other bits of information happen to live) that would
be great.

Monty Taylor <mailto:mord...@inaugust.com>
April 4, 2017 at 5:47 PM
Hey all,

As per our discussion in today's TC meeting, I have made a document 
format for reporting versions to the project navigator. I stuck it in 
the releases repo:


  https://review.openstack.org/453361

Because there was already per-release information there, and the 
governance repo did not have that structure.


I've included pseudo-code and a human explanation of how to get from a 
service's version discovery document to the data in this document, but 
also how it can be maintained- which is likely to be easier by hand 
than by automation - but who knows, maybe we decide we want to make a 
devstack job for each service that runs on tag events that submits a 
patch to the releases repo. That sounds like WAY more work than once a 
cycle someone adding a few lines of json to a repo - but *shrug*.


Basing it on the version discovery docs show a few things:

* "As a user, I want to consume an OpenStack Service's Discovery 
Document" is a thing people might want to do and want to do 
consistently across services.


* We're not that far off from being able to do that today.

* Still, like we are in many places, we're randomly different in a few 
minor ways that do not actually matter but make life harder for our 
users.


Thoughts and feedback more than welcome!
Monty

__ 


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] [tc] version document for project navigator

2017-04-05 Thread Jimmy McArthur

FWIW, from my perspective on the Project Navigator side, this format 
works great. We can actually derive the age of the project from this 
information as well by identifying the first release that has API data 
for a particular project. I'm indifferent about where it lives, so I'd 
defer to you all to determine the best spot.


I really appreciate you all putting this together!

Jimmy


Thierry Carrez 
April 5, 2017 at 5:28 AM

Somehow missed this thread, so will repost here comments I made elsewhere:

This looks good, but I would rather not overload the releases
repository. My personal preference (which was also expressed by
Doug in the TC meeting) would be to set this information up in a
"project-navigator" git repo that we would reuse for any information we
need to collect from projects for accurate display on the project
navigator. If the data is not maintained anywhere else (or easily
derivable from existing data), we would use that repository to collect
it from projects.

That way there is a clear place to go to to propose fixes to the project
navigator data. Not knowing how to fix that data is a common complaint,
so if we can point people to a git repo (and redirect people from there
to the places where other bits of information happen to live) that would
be great.

Monty Taylor 
April 4, 2017 at 5:47 PM
Hey all,

As per our discussion in today's TC meeting, I have made a document 
format for reporting versions to the project navigator. I stuck it in 
the releases repo:


  https://review.openstack.org/453361

Because there was already per-release information there, and the 
governance repo did not have that structure.


I've included pseudo-code and a human explanation of how to get from a 
service's version discovery document to the data in this document, but 
also how it can be maintained- which is likely to be easier by hand 
than by automation - but who knows, maybe we decide we want to make a 
devstack job for each service that runs on tag events that submits a 
patch to the releases repo. That sounds like WAY more work than once a 
cycle someone adding a few lines of json to a repo - but *shrug*.


Basing it on the version discovery docs show a few things:

* "As a user, I want to consume an OpenStack Service's Discovery 
Document" is a thing people might want to do and want to do 
consistently across services.


* We're not that far off from being able to do that today.

* Still, like we are in many places, we're randomly different in a few 
minor ways that do not actually matter but make life harder for our 
users.


Thoughts and feedback more than welcome!
Monty

__ 


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] [tc] version document for project navigator

2017-04-04 Thread Jimmy McArthur


Hooray! Thanks Monty :)


Monty Taylor 
April 4, 2017 at 5:47 PM
Hey all,

As per our discussion in today's TC meeting, I have made a document 
format for reporting versions to the project navigator. I stuck it in 
the releases repo:


  https://review.openstack.org/453361

Because there was already per-release information there, and the 
governance repo did not have that structure.


I've included pseudo-code and a human explanation of how to get from a 
service's version discovery document to the data in this document, but 
also how it can be maintained- which is likely to be easier by hand 
than by automation - but who knows, maybe we decide we want to make a 
devstack job for each service that runs on tag events that submits a 
patch to the releases repo. That sounds like WAY more work than once a 
cycle someone adding a few lines of json to a repo - but *shrug*.


Basing it on the version discovery docs show a few things:

* "As a user, I want to consume an OpenStack Service's Discovery 
Document" is a thing people might want to do and want to do 
consistently across services.


* We're not that far off from being able to do that today.

* Still, like we are in many places, we're randomly different in a few 
minor ways that do not actually matter but make life harder for our 
users.


Thoughts and feedback more than welcome!
Monty

__ 


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] Project Navigator Updates - Feedback Request

2017-04-03 Thread Jimmy McArthur

Yes, you need to be added to the Ops Tags here: 
https://github.com/openstack/ops-tags-team/tree/master/ocata  That's 
part of the Adoption and Maturity tags.



Afek, Ifat (Nokia - IL/Kfar Sava) <mailto:ifat.a...@nokia.com>
April 3, 2017 at 2:16 AM

Hi Jimmy,

Regarding the difference between neutron.yaml and vitrage.yaml – the 
only thing I see is the different release-model. Anything else that I 
missed?


Thanks,

Ifat.

*From: *Jimmy McArthur <ji...@openstack.org>
*Reply-To: *"OpenStack Development Mailing List (not for usage 
questions)" <openstack-dev@lists.openstack.org>

*Date: *Thursday, 30 March 2017 at 19:23
*To: *"OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
*Subject: *Re: [openstack-dev] Project Navigator Updates - Feedback 
Request




*Afek, Ifat (Nokia - IL/Kfar Sava)* <mailto:ifat.a...@nokia.com>

March 30, 2017 at 11:01 AM



Under “API Versions” there should also be Newton

This is something we are currently attempting to sort out. Projects 
don't have a consistent method for listing the APIs. See previous thread.


Why aren’t the adoption and maturity specified?

In order for us to get more info about your project, we need to have 
the proper tags. Compare 
http://git.openstack.org/cgit/openstack/releases/plain/deliverables/ocata/neutron.yaml 
vs 
http://git.openstack.org/cgit/openstack/releases/plain/deliverables/ocata/vitrage.yaml   
As well as here: 
https://github.com/openstack/ops-tags-team/tree/master/ocata


Thanks,
Jimmy

__
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
Jimmy McArthur <mailto:ji...@openstack.org>
March 30, 2017 at 11:23 AM


Afek, Ifat (Nokia - IL/Kfar Sava) <mailto:ifat.a...@nokia.com>
March 30, 2017 at 11:01 AM


·Under “API Versions” there should also be Newton

This is something we are currently attempting to sort out. Projects 
don't have a consistent method for listing the APIs. See previous thread.


·Why aren’t the adoption and maturity specified?

In order for us to get more info about your project, we need to have 
the proper tags. Compare 
http://git.openstack.org/cgit/openstack/releases/plain/deliverables/ocata/neutron.yaml 
vs 
http://git.openstack.org/cgit/openstack/releases/plain/deliverables/ocata/vitrage.yaml   
As well as here: 
https://github.com/openstack/ops-tags-team/tree/master/ocata


Thanks,
Jimmy


Thanks,

Ifat.

*From: *Lauren Sell <lau...@openstack.org>
*Reply-To: *"OpenStack Development Mailing List (not for usage 
questions)" <openstack-dev@lists.openstack.org>

*Date: *Friday, 24 March 2017 at 19:57
*To: *"OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>

*Subject: *[openstack-dev] Project Navigator Updates - Feedback Request

Hi everyone,

We’ve been talking for some time about updating the project 
navigator, and we have a draft ready to share for community feedback 
before we launch and publicize it. One of the big goals coming out of 
the joint TC/UC/Board meeting a few weeks ago[1] was to help better 
communicate ‘what is openstack?’ and this is one step in that direction.


A few goals in mind for the redesign:
- Represent all official, user-facing projects and deployment 
services in the navigator
- Better categorize the projects by function in a way that makes 
sense to prospective users (this may evolve over time as we work on 
mapping the OpenStack landscape)

- Help users understand which projects are mature and stable vs emerging
- Highlight popular project sets and sample configurations based on 
different use cases to help users get started


For a bit of context, we’re working to give each OpenStack official 
project a stronger platform as we think of OpenStack as a framework 
of composable infrastructure services that can be used individually 
or together as a powerful system. This includes the project 
mascots (so we in effect have logos to promote each component 
separately), updates to the project navigator, and bringing back the 
“project updates” track at the Summit to give each PTL/core team a 
chance to provide an update on their project roadmap (to be recorded 
and promoted in the project navigator among other places!).


We want your feedback on the project navigator v2 before it launches. 
Please take a look at the current version on the staging site and 
provide feedback on this thread.


http://devbranch.openstack.org/software/project-navigator/

Please review the overall concept and the data and description for 
your project specifically. The data is primarily pulled from TC 
tags[2] and Ops tags[3]. You’ll notice some projects have more 
information avai

Re: [openstack-dev] Project Navigator Updates - Feedback Request

2017-03-31 Thread Jimmy McArthur

I think this is a bit of a roadblock for us getting the new Navigator
up, so the sooner we can come to a decision the better :) Thanks for
raising the issue with the TC!

Thierry Carrez <mailto:thie...@openstack.org>
March 31, 2017 at 3:43 AM

I like the idea to provide unified API information, however I'm not sure
the Technical Committee should stand in the way of getting that
information updated. The less we force through strict governance
processes, the better, so everything that can be maintained by some
other group should be.

This is closer to documentation than governance, so I wonder if this
document should not be maintained at the API WG or the Docs team or
service catalog level -- just keeping the same team names so that
information can be easily cross-referenced with the governance repository.

I'll raise the discussion in open discussion at the next TC meeting.

Brian Rosmaita <mailto:rosmaita.foss...@gmail.com>
March 29, 2017 at 9:23 PM
On 3/29/17 12:55 AM, Jimmy McArthur wrote:
[snip]

See what you think of these. They add an "apis" section to the glance
section of projects.yaml in the governance repo.

http://paste.openstack.org/show/604775/ has a complete history, where
for each release, the complete set of versions of the API that are
available in that release (and their statuses) are listed.

http://paste.openstack.org/show/604776/ has an abbreviated history,
where only the changes in available APIs are listed from version to
version, and if there's no change, the release isn't listed at all.

I don't know if this format would work for microversions, though. (And
I don't know if it's a good idea in the first place.)

__
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
Jimmy McArthur <mailto:ji...@openstack.org>
March 28, 2017 at 11:55 PM

Brian,

Thanks for the response. This is a tough one. Currently we're pulling
API data manually for each project. That is no longer tenable when
we're talking about 40+ projects. Plus, this is info is something that
is really sought after by the community. Some thoughts below:

Brian Rosmaita <mailto:rosmaita.foss...@gmail.com>
March 28, 2017 at 10:25 PM
On 3/27/17 5:01 PM, Lauren Sell wrote:
I don't have a helpful recommendation here, but the version history
for Glance is incorrect as well. We maintain a version history in the
glance api-ref [0], but that's probably not much help (and, as you
point out, is idiosyncratic to Glance anyway). At this point, though,
my primary concern is that it's showing a deprecated API version as
the latest release. What format would it be useful for you to get
this data in?

What we really need is the following:

* A project history, including the date of project inception that's
included in the TC tags.
* An API history in an easily digestible format that all projects
share. So whether you're doing micro releases or not, just something
that allows us to show, based on a release timeline, which API
versions per project are applicable for each OpenStack release. This
really needs to be consistent from project to project b/c at the
moment everyone handles it differently.

thanks,
brian

[0]
https://developer.openstack.org/api-ref/image/versions/index.html#version-history

__
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
Brian Rosmaita <mailto:rosmaita.foss...@gmail.com>
March 28, 2017 at 10:25 PM
On 3/27/17 5:01 PM, Lauren Sell wrote:

Hi Matt,

Thanks for the feedback.

On Mar 24, 2017, at 3:50 PM, Matt Riedemann<mriede...@gmail.com> wrote:

[snip]

2. The "API Version History" section in the bottom right says:

"Version v2.1 (Ocata) - LATEST RELEASE"

And links to https://releases.openstack.org/<https://releases.openstack.org/>.
The latest compute microversion in Ocata was actually 2.42:

https://docs.openstack.org/developer/nova/api_microversion_history.html<https://docs.openstack.org/developer/nova/api_microversion_history.html>

I'm wondering how we can better sort that out. I guess "API Version History" in
the navigator is meant more for major versions and wasn't intended to handle
microversions? That seems like something that should be dealt with at some point as more
and more projects

Re: [openstack-dev] Project Navigator Updates - Feedback Request

2017-03-30 Thread Jimmy McArthur




Afek, Ifat (Nokia - IL/Kfar Sava) 
March 30, 2017 at 11:01 AM


·Under “API Versions” there should also be Newton

This is something we are currently attempting to sort out. Projects 
don't have a consistent method for listing the APIs. See previous thread.


·Why aren’t the adoption and maturity specified?

In order for us to get more info about your project, we need to have the 
proper tags. Compare 
http://git.openstack.org/cgit/openstack/releases/plain/deliverables/ocata/neutron.yaml 
vs 
http://git.openstack.org/cgit/openstack/releases/plain/deliverables/ocata/vitrage.yaml   
As well as here: 
https://github.com/openstack/ops-tags-team/tree/master/ocata


Thanks,
Jimmy


Thanks,

Ifat.

*From: *Lauren Sell 
*Reply-To: *"OpenStack Development Mailing List (not for usage 
questions)" 

*Date: *Friday, 24 March 2017 at 19:57
*To: *"OpenStack Development Mailing List (not for usage questions)" 


*Subject: *[openstack-dev] Project Navigator Updates - Feedback Request

Hi everyone,

We’ve been talking for some time about updating the project navigator, 
and we have a draft ready to share for community feedback before we 
launch and publicize it. One of the big goals coming out of the joint 
TC/UC/Board meeting a few weeks ago[1] was to help better communicate 
‘what is openstack?’ and this is one step in that direction.


A few goals in mind for the redesign:
- Represent all official, user-facing projects and deployment services 
in the navigator
- Better categorize the projects by function in a way that makes sense 
to prospective users (this may evolve over time as we work on mapping 
the OpenStack landscape)

- Help users understand which projects are mature and stable vs emerging
- Highlight popular project sets and sample configurations based on 
different use cases to help users get started


For a bit of context, we’re working to give each OpenStack official 
project a stronger platform as we think of OpenStack as a framework of 
composable infrastructure services that can be used individually or 
together as a powerful system. This includes the project mascots (so 
we in effect have logos to promote each component separately), updates 
to the project navigator, and bringing back the “project updates” 
track at the Summit to give each PTL/core team a chance to provide an 
update on their project roadmap (to be recorded and promoted in the 
project navigator among other places!).


We want your feedback on the project navigator v2 before it launches. 
Please take a look at the current version on the staging site and 
provide feedback on this thread.


http://devbranch.openstack.org/software/project-navigator/

Please review the overall concept and the data and description for 
your project specifically. The data is primarily pulled from TC 
tags[2] and Ops tags[3]. You’ll notice some projects have more 
information available than others for various reasons. That’s one 
reason we decided to downplay the maturity metric for now and the data 
on some pages is hidden. If you think your project is missing data, 
please check out the repositories and submit changes or again respond 
to this thread.


Also know this will continue to evolve and we are open to feedback. As 
I mentioned, a team that formed at the joint strategy session a few 
weeks ago is tackling how we map OpenStack projects, which may be 
reflected in the categories. And I suspect we’ll continue to build out 
additional tags and better data sources to be incorporated.


Thanks for your feedback and help.

Best,
Lauren

[1] 
http://superuser.openstack.org/articles/community-leadership-charts-course-openstack/

[2] https://governance.openstack.org/tc/reference/tags/
[3] https://wiki.openstack.org/wiki/Operations/Tags

__
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] Project Navigator Updates - Feedback Request

2017-03-30 Thread Jimmy McArthur

This (http://paste.openstack.org/show/604775/) is absolutely perfect. I
feel like the format could work for microversions as well. Anyone from
Neutron or another microversion project that could weigh in?

Another great thing about this, is we can use this API version history
to determine project age, which again is a manual thing we're doing
right now.

Thanks!! Would love to hear others opinions on this?

Brian Rosmaita <mailto:rosmaita.foss...@gmail.com>
March 29, 2017 at 9:23 PM
On 3/29/17 12:55 AM, Jimmy McArthur wrote:
[snip]

See what you think of these. They add an "apis" section to the glance
section of projects.yaml in the governance repo.

http://paste.openstack.org/show/604775/ has a complete history, where
for each release, the complete set of versions of the API that are
available in that release (and their statuses) are listed.

I don't know if this format would work for microversions, though. (And
I don't know if it's a good idea in the first place.)

__
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
Jimmy McArthur <mailto:ji...@openstack.org>
March 28, 2017 at 11:55 PM

Brian,

What we really need is the following:

thanks,
brian

[0]
https://developer.openstack.org/api-ref/image/versions/index.html#version-history

__
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
Brian Rosmaita <mailto:rosmaita.foss...@gmail.com>
March 28, 2017 at 10:25 PM
On 3/27/17 5:01 PM, Lauren Sell wrote:

Hi Matt,

Thanks for the feedback.

On Mar 24, 2017, at 3:50 PM, Matt Riedemann<mriede...@gmail.com> wrote:

[snip]

2. The "API Version History" section in the bottom right says:

"Version v2.1 (Ocata) - LATEST RELEASE"

And links to https://releases.openstack.org/<https://releases.openstack.org/>.
The latest compute microversion in Ocata was actually 2.42:

https://docs.openstack.org/developer/nova/api_microversion_history.html<https://docs.openstack.org/developer/nova/api_microversion_history.html>

Agreed, we could use some guidance here. From what we can tell, each team logs
these a little bit differently, so there's no easy way for us to pull them.
Could we output the correct link as a tag for each project, or does anyone have
a recommendation?

I don't have a helpful recommendation here, but the version history for
Glance is incorrect as well. We maintain a version history in the
glance api-ref [0], but that's probably not mu

Re: [openstack-dev] Project Navigator Updates - Feedback Request

2017-03-28 Thread Jimmy McArthur



Brian,

Thanks for the response. This is a tough one. Currently we're pulling 
API data manually for each project. That is no longer tenable when we're 
talking about 40+ projects. Plus, this is info is something that is 
really sought after by the community. Some thoughts below:

Brian Rosmaita 
March 28, 2017 at 10:25 PM
On 3/27/17 5:01 PM, Lauren Sell wrote:
I don't have a helpful recommendation here, but the version history 
for Glance is incorrect as well. We maintain a version history in the 
glance api-ref [0], but that's probably not much help (and, as you 
point out, is idiosyncratic to Glance anyway). At this point, though, 
my primary concern is that it's showing a deprecated API version as 
the latest release. What format would it be useful for you to get this 
data in?

What we really need is the following:

* A project history, including the date of project inception that's 
included in the TC tags.
* An API history in an easily digestible format that all projects share. 
So whether you're doing micro releases or not, just something that 
allows us to show, based on a release timeline, which API versions per 
project are applicable for each OpenStack release. This really needs to 
be consistent from project to project b/c at the moment everyone handles 
it differently.


thanks,
brian

[0]
https://developer.openstack.org/api-ref/image/versions/index.html#version-history

__
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] [barbican] Project Navigator Out of Date

2017-01-16 Thread Jimmy McArthur

Hi all. Just wanted to throw out that if you have bug reports or issues 
with the content on the project navigator, please feel free to send them 
to https://bugs.launchpad.net/openstack-org/ and someone on the 
Foundation Staff will look into it. I've already fielded a one for 
Designate this morning, which we just pushed a patch out for.


If you have other concerns that weren't already addressed by fifieldt or 
ttx, please let me know.


Cheers,
Jimmy

__
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] Barcelona Summit - Speaker slide upload problem

2016-12-13 Thread Jimmy Mcarthur

The issue with file size uploads is resolved. Should be all good to go 
now. Thanks for your patience!


Jimmy


Jimmy Mcarthur <mailto:ji...@tipit.net>
December 13, 2016 at 10:46 AM
Hi all -

A quick note for those of you that have had trouble uploading slides 
for your Barcelona presentation.  We are working on the file size 
issue, which is throwing some errors on the site. Hope to have a fix 
up shortly, and apologies for the trouble.


Thank you,
Jimmy McArthur


__
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] Barcelona Summit - Speaker slide upload problem

2016-12-13 Thread Jimmy Mcarthur


Hi all -

A quick note for those of you that have had trouble uploading slides for 
your Barcelona presentation.  We are working on the file size issue, 
which is throwing some errors on the site. Hope to have a fix up 
shortly, and apologies for the trouble.


Thank you,
Jimmy McArthur

__
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

2016-11-07 Thread Jimmy McArthur

Hi all - Wanted to circle back on this now that we're clear of the 
Summit madness. Someone had asked for assistance on getting OpenStackID 
up and running on this. Is that still a need? If so, let me know how we 
can help.


Thank you,
Jimmy


Chris Dent 
September 21, 2016 at 3:47 PM
On Wed, 21 Sep 2016, Boden Russell wrote:


For channels that are configured to have purplerbot running, you can
get that with p!spy. See https://anticdent.org/purple-irc-bot.html

If you want the bot added to a channel let me know, or run your own;
the code is linked from the blog post.

__
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
Boden Russell 
September 21, 2016 at 1:22 PM

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
Asselin, Ramy 
September 19, 2016 at 11:54 AM

Very nice, thanks!

Only change I'll suggest is to allow it to be enabled by default J

Ramy

*From:* Bashmakov, Alexander [mailto:alexander.bashma...@intel.com]
*Sent:* Friday, September 16, 2016 2:26 PM
*To:* OpenStack Development Mailing List (not for usage questions) 

*Subject:* [openstack-dev] [all] Useful tool for easier viewing of IRC 
logs online


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


__
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] Project Navigator - Maturity Metrics

2016-09-19 Thread Jimmy McArthur

Shamail <mailto:itzsham...@gmail.com>
September 19, 2016 at 11:32 AM

On Sep 19, 2016, at 12:22 PM, Jimmy McArthur<ji...@openstack.org> wrote:

Gordon,

Thanks for brining this to our attention. We pull data from many different sources for the
Navigator. Most of the attributions for that data can be found under "Tag Details" or
various "?" modal links on the page. For PTLs, we grab that data from the following:
https://raw.githubusercontent.com/openstack/governance/master/reference/projects.yaml. All data is
pulled using a nightly cronjob.

However, it appears there is an error in the yaml that's preventing the data
from being pulled. We're working to resolve the problem now. I'd like to
suggest the following to prevent this moving forward:

* Add an email alert to the cronjob that pulls data. In the event of an error,
send an alert to myself, Thierry Carez and Tom Fifeld to let us know if the
ingest process fails

+1 (feel free to add me as well)

* Change "PTL for Latest Release" to "Current PTL", to avoid confusion

+1, great idea (also removes the reference to releases which could be different
things to independent release projects)

* Add IRC-Channel of project and IRC handle of PTL to help users get to the
right spot

Where will you pull this information from or will we manually add it? If we add
IRC information then we should also add the info as a web client link.
IRC info is available in the same file
(https://raw.githubusercontent.com/openstack/governance/master/reference/projects.yaml).

Thanks!
Jimmy McArthur

is this updated with a script or manually? i just took a quick look at
this and some of the projects have a different information between the
high-level "all projects" view and the detailed individual project view.
this was something that was brought up a months ago so i assume it
hasn't been looked at in a while.

for example, i'm not a PTL but it says i am one.

__
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
Jimmy McArthur <mailto:ji...@openstack.org>
September 19, 2016 at 11:22 AM
Gordon,

Thanks for brining this to our attention. We pull data from many
different sources for the Navigator. Most of the attributions for that
data can be found under "Tag Details" or various "?" modal links on
the page. For PTLs, we grab that data from the following:
https://raw.githubusercontent.com/openstack/governance/master/reference/projects.yaml.
All data is pulled using a nightly cronjob.

However, it appears there is an error in the yaml that's preventing
the data from being pulled. We're working to resolve the problem now.
I'd like to suggest the following to prevent this moving forward:

* Add an email alert to the cronjob that pulls data. In the event of
an error, send an alert to myself, Thierry Carez and Tom Fifeld to let
us know if the ingest process fails

* Change "PTL for Latest Release" to "Current PTL", to avoid confusion
* Add IRC-Channel of project and IRC handle of PTL to help users get
to the right spot

Thanks!
Jimmy McArthur

for example, i'm not a PTL but it says i am one.

[openstack-dev] [Product] Project Navigator - Maturity Metrics

2016-09-19 Thread Jimmy McArthur


Gordon,

Thanks for brining this to our attention. We pull data from many 
different sources for the Navigator. Most of the attributions for that 
data can be found under "Tag Details" or various "?" modal links on the 
page. For PTLs, we grab that data from the following: 
https://raw.githubusercontent.com/openstack/governance/master/reference/projects.yaml. 
All data is pulled using a nightly cronjob.


However, it appears there is an error in the yaml that's preventing the 
data from being pulled. We're working to resolve the problem now. I'd 
like to suggest the following to prevent this moving forward:


* Add an email alert to the cronjob that pulls data. In the event of an 
error, send an alert to myself, Thierry Carez and Tom Fifeld to let us 
know if the ingest process fails

* Change "PTL for Latest Release" to "Current PTL", to avoid confusion
* Add IRC-Channel of project and IRC handle of PTL to help users get to 
the right spot


Thanks!
Jimmy McArthur

is this updated with a script or manually? i just took a quick look at
this and some of the projects have a different information between the
high-level "all projects" view and the detailed individual project view.
this was something that was brought up a months ago so i assume it
hasn't been looked at in a while.

for example, i'm not a PTL but it says i am one.



__
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] Seeking Mobile Beta Testers

2016-09-06 Thread Jimmy McArthur


Hi all -

I've got a handful of volunteers (BCC'd here), which should be plenty 
for round 1. Please expect some further communication with me this 
afternoon with details on how to access the app, what to test, and to 
log in, etc...


Thank you for the assist!
Jimmy McArthur


Major Hayden <mailto:ma...@mhtx.net>
September 6, 2016 at 8:04 AM

I'll gladly help with Android testing on my Moto X.

--
Major Hayden
Jimmy McArthur <mailto:ji...@openstack.org>
September 2, 2016 at 12:57 PM
We're looking for a handful of community members to test our updated 
OpenStack Summit mobile Apps. If you're interested, shoot me a note, 
along with iOS/Android preference, and we'll get you set up.


Thank you,
Jimmy McArthur



__
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] Seeking Mobile Beta Testers

2016-09-02 Thread Jimmy McArthur

We're looking for a handful of community members to test our updated 
OpenStack Summit mobile Apps. If you're interested, shoot me a note, 
along with iOS/Android preference, and we'll get you set up.


Thank you,
Jimmy McArthur


__
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] My openstack account is invalid after change it

2016-08-24 Thread Jimmy Mcarthur


Hi -

I'd be happy to assist you with your login problem. Please email me 
directly and we'll get you going.


Thank you!
Jimmy McArthur

I changed my openstack account to my new email address because my old email 
address is abandoned, now i can not login with my new email address, it prompts 
my new email address is not verified, every time I click verify my new account,
It prompts " your request was successfully processed! please verify your 
INBOX", but I never receive email about it.

I guess it sends verification email to my our email address, what should I do 
because my old email address can not be used?



__
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] [Openstack-track-chairs] [all][summit] Responding to questions on submitted summit talk?

2016-07-25 Thread Jimmy Mcarthur

If anyone else is out there that isn't sure where to respond, please 
send a ticket into speakersupp...@openstack.org and I'll get you all 
squared away.


THanks,
Jimmy

Ben Nemec wrote:

Sent.  Thanks for looking into this.

-Ben

On 07/25/2016 10:58 AM, Jimmy Mcarthur wrote:

speakersupp...@openstack.org, plus the track chairs, should be cc'd on
any email from the Track Chairs too. Would you mind forwarding me a copy
of the email you received?

Thank you,
Jimmy McArthur
Summit Speaker Support

Ulrich Kleber wrote:

Hi,
it seems the tooling didn't consider that.
I forward this for you to the track chairs, since I am not sure whether you 
will be able to post to the mailing list.
Thanks for letting us know.
Cheers,
Uli

-Original Message-
From: Ben Nemec [mailto:openst...@nemebean.com]
Sent: Monday, 25 July, 2016 17:32
To: Nikhil Komawar; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][summit] Responding to questions on submitted 
summit talk?

Okay, I sent the question there too.  I figured I would try -dev because 
somebody here might know and it's of general interest to the community.
I'll let everyone know if/when I get a response from the summit folks.

On 07/25/2016 10:15 AM, Nikhil Komawar wrote:

I think this may be the wrong place to ask such info because all the
process on summit presentation is being handled by folks who are not
necessarily openstack developers.

Please follow:
https://www.openstack.org/summit/barcelona-2016/call-for-presentations
/selection-process and send email to summit [at] openstack [dot] org
<mailto:sum...@openstack.org>  as required.

On 7/25/16 10:55 AM, Ben Nemec wrote:

Hi,

I got a question from one of the track chairs on my presentation, but
the email came from a noreply address and I don't see anywhere on the
submission page that I can respond to feedback.  How are we supposed
to do that?

Thanks.

-Ben

_
_ 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-track-chairs mailing list
openstack-track-cha...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-track-chairs




__
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] [Openstack-track-chairs] [all][summit] Responding to questions on submitted summit talk?

2016-07-25 Thread Jimmy Mcarthur

speakersupp...@openstack.org, plus the track chairs, should be cc'd on 
any email from the Track Chairs too. Would you mind forwarding me a copy 
of the email you received?


Thank you,
Jimmy McArthur
Summit Speaker Support

Ulrich Kleber wrote:

Hi,
it seems the tooling didn't consider that.
I forward this for you to the track chairs, since I am not sure whether you 
will be able to post to the mailing list.
Thanks for letting us know.
Cheers,
Uli

-Original Message-
From: Ben Nemec [mailto:openst...@nemebean.com]
Sent: Monday, 25 July, 2016 17:32
To: Nikhil Komawar; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][summit] Responding to questions on submitted 
summit talk?

Okay, I sent the question there too.  I figured I would try -dev because 
somebody here might know and it's of general interest to the community.
I'll let everyone know if/when I get a response from the summit folks.

On 07/25/2016 10:15 AM, Nikhil Komawar wrote:

I think this may be the wrong place to ask such info because all the
process on summit presentation is being handled by folks who are not
necessarily openstack developers.

Please follow:
https://www.openstack.org/summit/barcelona-2016/call-for-presentations
/selection-process and send email to summit [at] openstack [dot] org
<mailto:sum...@openstack.org>  as required.

On 7/25/16 10:55 AM, Ben Nemec wrote:

Hi,

I got a question from one of the track chairs on my presentation, but
the email came from a noreply address and I don't see anywhere on the
submission page that I can respond to feedback.  How are we supposed
to do that?

Thanks.

-Ben

_
_ 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-track-chairs mailing list
openstack-track-cha...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-track-chairs


__
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] Fwd: [kolla][security][infra][ops] Kolla Design Summit Agenda Published

2016-04-18 Thread Jimmy McArthur


Hi All -

Just a quick note to let you konw that you do not need to re-download 
the app in order to get Schedule updates. We do have a cached API, so it 
might take a few minutes for it to update. We also limit the # of 
updates to 30 at a time so your app doesn't crash in the event of a slow 
network / bad connection. Once the core set of data is uploaded, future 
updates are pretty quick.


Please feel free to send an email to summit...@openstack.org if you 
still have trouble, but this particular issue should not be occurring.


Thanks!
Jimmy McArthur

Jonathan Bryce wrote:




Begin forwarded message:

*From: *"Steven Dake (stdake)" <std...@cisco.com 
<mailto:std...@cisco.com>>
*Subject: **[openstack-dev] [kolla][security][infra][ops] Kolla 
Design Summit Agenda Published*

*Date: *April 17, 2016 at 8:14:00 PM CDT
*To: *"OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org 
<mailto:openstack-dev@lists.openstack.org>>
*Reply-To: *"OpenStack Development Mailing List \(not for usage 
questions\)" <openstack-dev@lists.openstack.org 
<mailto:openstack-dev@lists.openstack.org>>


OpenStackers,

The full Kolla summit agenda is here:
https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Kolla%3A

We would super appreciate any operator presence in our fishbowl or 
design sessions so we do right by the Operators that use Kolla 
community generated code including documentation.


If folks have conflicts, please email me off list and I'll make an 
effort to rearrange the agenda if feasible.  I am especially willing 
to move around design sessions tagged with security or infrastructure 
if the security or infrastructure team has conflicts.  I am not 
certain when my ability to re-arrange schedules will end, so please 
mail as soon as possible.


NB for the security team and the kolla coresec team.:

I have scheduled 3 hours for TA.  We begin this process Thursday @ 
11:50 AM here:

https://www.openstack.org/summit/austin-2016/summit-schedule/events/9307?goback=1

And finish Friday morning here:
https://www.openstack.org/summit/austin-2016/summit-schedule/events/9400?goback=1

I have heard you may need to re-download the phone application if you 
have it already downloaded it because of how it caches, but don't 
have data to back up this claim.  If the schedule looks out of date, 
try that workaround.  If that doesn't work, contact me (irc nick 
sdake) on #openstack-kolla on IRC and we can work together with the 
#openstack-infra team to get you setup.


Regards,
-steve
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org 
<mailto: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] Project Navigator Updates - Feedback Request

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

Re: [openstack-dev] [Cinder][Nova] Scheduling issue for the Summit

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

Re: [openstack-dev] [tc] version document for project navigator

Re: [openstack-dev] [tc] version document for project navigator

Re: [openstack-dev] [tc] version document for project navigator

Re: [openstack-dev] [tc] version document for project navigator

Re: [openstack-dev] [tc] version document for project navigator

Re: [openstack-dev] [tc] version document for project navigator

Re: [openstack-dev] [tc] version document for project navigator

Re: [openstack-dev] Project Navigator Updates - Feedback Request

Re: [openstack-dev] Project Navigator Updates - Feedback Request

Re: [openstack-dev] Project Navigator Updates - Feedback Request

Re: [openstack-dev] Project Navigator Updates - Feedback Request

Re: [openstack-dev] Project Navigator Updates - Feedback Request

[openstack-dev] [barbican] Project Navigator Out of Date

Re: [openstack-dev] Barcelona Summit - Speaker slide upload problem

[openstack-dev] Barcelona Summit - Speaker slide upload problem

Re: [openstack-dev] [all] Useful tool for easier viewing of IRC logs online

Re: [openstack-dev] [Product] Project Navigator - Maturity Metrics

[openstack-dev] [Product] Project Navigator - Maturity Metrics

Re: [openstack-dev] Seeking Mobile Beta Testers

[openstack-dev] Seeking Mobile Beta Testers

Re: [openstack-dev] My openstack account is invalid after change it

Re: [openstack-dev] [Openstack-track-chairs] [all][summit] Responding to questions on submitted summit talk?

Re: [openstack-dev] [Openstack-track-chairs] [all][summit] Responding to questions on submitted summit talk?

Re: [openstack-dev] Fwd: [kolla][security][infra][ops] Kolla Design Summit Agenda Published

< 1 2

101 - 128 of 128 matches

Site Navigation

Mail list logo

Footer information