Re: [openstack-dev] [Zun] Announce change of Zun core reviewer team

[Shuai Zhao]

+1 for Ji Wei :-)

On Thu, May 3, 2018 at 4:40 AM, Hongbin Lu  wrote:

> Hi all,
>
> I would like to announce the following change on the Zun core reviewers
> team:
>
> + Ji Wei
>
> Ji Wei has been working on Zun for a while. His contributions include
> blueprints, bug fixes, code reviews, etc. In particular, I would like to
> highlight that he has implemented two blueprints [1][2], both of which are
> not easy to implement. Based on his high-quality work in the past, I
> believe he will serve the core reviewer role very well.
>
> This proposal had been voted within the existing core team and was
> unanimously approved. Welcome to the core team Ji Wei.
>
> [1] https://blueprints.launchpad.net/zun/+spec/glance-support-tag
> [2] https://blueprints.launchpad.net/zun/+spec/zun-rebuild-on-local-node
>
> Best regards,
> Hongbin
>
>
> __
> 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] [tripleo] validating overcloud config changes on a redeploy

[Alex Schultz]

On Fri, Apr 27, 2018 at 9:49 AM, Ade Lee  wrote:
> Hi,
>
> Recently I starting looking at how we implement password changes in an
> existing deployment, and found that there were issues.  This made me
> wonder whether we needed a test job to confirm that password changes
> (and other config changes) are in fact executed properly.
>
> As far as I understand it, the way to do password changes is to -
> 1) Create a yaml file containing the parameters to be changed and
>their new values
> 2) call openstack overcloud deploy and append -e new_params.yaml
>
> Note that the above steps can really describe the testing of setting
> any config changes (not just passwords).
>
> Of course, if we do change passwords, we'll want to validate that the
> config files have changed, the keystone/dbusers have been modified, the
> mistral plan has been updated, services are still running etc.
>
> After talking with many folks, it seems there is no clear consensus
> where code to do the above tasks should live.  Should it be in tripleo-
> upgrades, or in tripleo-validations or in a separate repo?
>
> Is there anyone already doing something similar?
>
> If we end up creating a role to do this, ideally it should be
> deployment tool agnostic - usable by both infrared or quickstart or
> others.
>
> Whats the best way to do this?
>

So in my mind, this falls under a testing framework validation where
we want to perform a set of $deployment_actions and ensure that
$specific_things have been completed. For the most part we don't have
anything like that in the upstream tripleo project for actions that
aren't covered by tempest tests.  Even tempest tests are only ensuring
that we configured the services so they work but not a state
transition from A to B.  Honestly I don't think tripleo-upgrades or
tripleo-validations is the appropriate place for this type of check.
tripleo-validations might make sense if we expected an end user to do
this after performing a specific action but I don't think there's
enough of these types of actions for that to be warrented.  It's more
likely that we would want to come up with a deployment test suite that
could be run offline where a scenario like 'change all the passwords'
would be executed and verified that it functioned as expected (all the
passwords were changed).  Something like this might work in a periodic
upstream job but it's more like a full validation suite that would
most likely need to be run offline.

Thanks,
-Alex

> Thanks,
> Ade
>
> __
> 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] [Zun] Announce change of Zun core reviewer team

[Kumari, Madhuri]

Welcome to the team, Ji Wei ☺

Regards,
Madhuri

From: Hongbin Lu [mailto:hongbin...@gmail.com]
Sent: Thursday, May 3, 2018 2:10 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [Zun] Announce change of Zun core reviewer team

Hi all,

I would like to announce the following change on the Zun core reviewers team:

+ Ji Wei

Ji Wei has been working on Zun for a while. His contributions include 
blueprints, bug fixes, code reviews, etc. In particular, I would like to 
highlight that he has implemented two blueprints [1][2], both of which are not 
easy to implement. Based on his high-quality work in the past, I believe he 
will serve the core reviewer role very well.

This proposal had been voted within the existing core team and was unanimously 
approved. Welcome to the core team Ji Wei.

[1] https://blueprints.launchpad.net/zun/+spec/glance-support-tag
[2] https://blueprints.launchpad.net/zun/+spec/zun-rebuild-on-local-node

Best regards,
Hongbin

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ironic] ironic_host_manager and baremetal scheduler options removal

[Matt Riedemann]

On 5/2/2018 12:39 PM, Matt Riedemann wrote:
FWIW, I think we can also backport the data migration CLI to stable 
branches once we have it available so you can do your migration in let's 
say Queens before g


FYI, here is the start on the data migration CLI:

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

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[melanie witt]

On Wed, 2 May 2018 17:45:37 -0500, Matt Riedemann wrote:

On 5/2/2018 5:39 PM, Jay Pipes wrote:

My personal preference is to add less technical debt and go with a
solution that checks if image traits have changed in nova-api and if so,
simply refuse to perform a rebuild.


So, what if when I created my server, the image I used, let's say
image1, had required trait A and that fit the host.

Then some external service removes (or somehow changes) trait A from the
compute node resource provider (because people can and will do this,
there are a few vmware specs up that rely on being able to manage traits
out of band from nova), and then I rebuild my server with image2 that
has required trait A. That would match the original trait A in image1
and we'd say, "yup, lgtm!" and do the rebuild even though the compute
node resource provider wouldn't have trait A anymore.

Having said that, it could technically happen before traits if the
operator changed something on the underlying compute host which
invalidated instances running on that host, but I'd think if that
happened the operator would be migrating everything off the host and
disabling it from scheduling before making whatever that kind of change
would be, let's say they change the hypervisor or something less drastic
but still image property invalidating.


This is a scenario I was thinking about too. In the land of software 
licenses, this would be analogous to removing a license from a compute 
host, say. The instance is already there but should we let a rebuild 
proceed that is going to violate the image traits currently supported by 
that host? Do we potentially prolong the life of that instance by 
letting it be re-imaged?


I'm late to this thread but I finally went through the replies and my 
thought is, we should do a pre-flight check to verify with placement 
whether the image traits requested are 1) supported by the compute host 
the instance is residing on and 2) coincide with the already-existing 
allocations. Instead of making an assumption based on "last image" vs 
"new image" and artificially limiting a rebuild that should be valid to 
go ahead. I can imagine scenarios where a user is trying to do a rebuild 
that their cloud admin says should be perfectly valid on their 
hypervisor, but it's getting rejected because old image traits != new 
image traits. It seems like unnecessary user and admin pain.


It doesn't seem correct to reject the request if the current compute 
host can fulfill it, and if I understood correctly, we have placement 
APIs we can call from the conductor to verify the image traits requested 
for the rebuild can be fulfilled. Is there a reason not to do that?


-melanie





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Arvind N]

Isnt this an existing issue with traits specified in flavor as well?

Server is created using flavor1 requiring trait A on RP1. Before the
rebuild is called, the underlying RP1 can be updated to remove trait A and
when a rebuild is requested(regardless of whether the image is updated or
not), we skip scheduling and allow the rebuild to go through.

Now, even though the flavor1 requests trait A, the underlying RP1 does not
have that trait the rebuild will succeed...

I think maybe there should be some kind of report or query which runs
periodically to ensure continued conformance with respect to instance
running and their traits. But since traits are intend to provide hints for
scheduling, this is different problem to solve IMO.

On Wed, May 2, 2018 at 3:45 PM, Matt Riedemann  wrote:

> On 5/2/2018 5:39 PM, Jay Pipes wrote:
>
>> My personal preference is to add less technical debt and go with a
>> solution that checks if image traits have changed in nova-api and if so,
>> simply refuse to perform a rebuild.
>>
>
> So, what if when I created my server, the image I used, let's say image1,
> had required trait A and that fit the host.
>
> Then some external service removes (or somehow changes) trait A from the
> compute node resource provider (because people can and will do this, there
> are a few vmware specs up that rely on being able to manage traits out of
> band from nova), and then I rebuild my server with image2 that has required
> trait A. That would match the original trait A in image1 and we'd say,
> "yup, lgtm!" and do the rebuild even though the compute node resource
> provider wouldn't have trait A anymore.
>
> Having said that, it could technically happen before traits if the
> operator changed something on the underlying compute host which invalidated
> instances running on that host, but I'd think if that happened the operator
> would be migrating everything off the host and disabling it from scheduling
> before making whatever that kind of change would be, let's say they change
> the hypervisor or something less drastic but still image property
> invalidating.
>
> --
>
> Thanks,
>
> Matt
>
>
> __
> 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
>



-- 
Arvind N
__
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-ansible] Implement rotations for meetings handling

[Marc Gariepy]

Also +1.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Matt Riedemann]

On 5/2/2018 5:39 PM, Jay Pipes wrote:
My personal preference is to add less technical debt and go with a 
solution that checks if image traits have changed in nova-api and if so, 
simply refuse to perform a rebuild.


So, what if when I created my server, the image I used, let's say 
image1, had required trait A and that fit the host.


Then some external service removes (or somehow changes) trait A from the 
compute node resource provider (because people can and will do this, 
there are a few vmware specs up that rely on being able to manage traits 
out of band from nova), and then I rebuild my server with image2 that 
has required trait A. That would match the original trait A in image1 
and we'd say, "yup, lgtm!" and do the rebuild even though the compute 
node resource provider wouldn't have trait A anymore.


Having said that, it could technically happen before traits if the 
operator changed something on the underlying compute host which 
invalidated instances running on that host, but I'd think if that 
happened the operator would be migrating everything off the host and 
disabling it from scheduling before making whatever that kind of change 
would be, let's say they change the hypervisor or something less drastic 
but still image property invalidating.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Jay Pipes]

On 05/02/2018 10:07 AM, Matt Riedemann wrote:

On 5/1/2018 5:26 PM, Arvind N wrote:
In cases of rebuilding of an instance using a different image where 
the image traits have changed between the original launch and the 
rebuild, is it reasonable to ask to just re-launch a new instance with 
the new image?


The argument for this approach is that given that the requirements 
have changed, we want the scheduler to pick and allocate the 
appropriate host for the instance.


We don't know if the requirements have changed with the new image until 
we check them.


Here is another option:

What if the API compares the original image required traits against the 
new image required traits, and if the new image has required traits 
which weren't in the original image, then (punt) fail in the API? Then 
you would at least have a chance to rebuild with a new image that has 
required traits as long as those required traits are less than or equal 
to the originally validated traits for the host on which the instance is 
currently running.


That's pretty much what I had suggested earlier, yeah.

Option 10: Don't support image-defined traits at all. I know that won't 
happen though.


At this point I'm exhausted with this entire issue and conversation and 
will probably bow out and need someone else to step in with different 
perspective, like melwitt or dansmith.


All of the solutions are bad in their own way, either because they add 
technical debt and poor user experience, or because they make rebuild 
more complicated and harder to maintain for the developers.


I hear your frustration. And I agree all of the solutions are bad in 
their own way.


My personal preference is to add less technical debt and go with a 
solution that checks if image traits have changed in nova-api and if so, 
simply refuse to perform a rebuild.


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Gerrit server replacement finished

[Paul Belanger]

Hello from Infra.
 
Gerrit maintenance has concluded successfully and running happily on Ubuntu
Xenial.  We were able to save and restore the queues from zuul, but as always
be sure to check your patches as a recheck maybe be required.

If you have any questions or comments, please reach out to us in
#openstack-infra.

I've leave the text below in case anybody missed our previous emails.

---

It's that time again... on Wednesday, May 02, 2018 20:00 UTC, the OpenStack
Project Infrastructure team is upgrading the server which runs
review.openstack.org to Ubuntu Xenial, and that means a new virtual machine
instance with new IP addresses assigned by our service provider. The new IP
addresses will be as follows:

IPv4 -> 104.130.246.32
IPv6 -> 2001:4800:7819:103:be76:4eff:fe04:9229

They will replace these current production IP addresses:

IPv4 -> 104.130.246.91
IPv6 -> 2001:4800:7819:103:be76:4eff:fe05:8525

We understand that some users may be running from egress-filtered
networks with port 29418/tcp explicitly allowed to the current
review.openstack.org IP addresses, and so are providing this
information as far in advance as we can to allow them time to update
their firewalls accordingly.

Note that some users dealing with egress filtering may find it
easier to switch their local configuration to use Gerrit's REST API
via HTTPS instead, and the current release of git-review has support
for that workflow as well.
http://lists.openstack.org/pipermail/openstack-dev/2014-September/045385.html

We will follow up with final confirmation in subsequent announcements.

Thanks,
Paul

__
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][docs] documenting openstack "constellations"

[Doug Hellmann]

Excerpts from Graham Hayes's message of 2018-05-02 20:15:14 +0100:
> On 02/05/18 20:11, Doug Hellmann wrote:
> > Excerpts from Zane Bitter's message of 2018-05-02 11:38:55 -0400:
> >> On 01/05/18 16:21, Doug Hellmann wrote:
> >>> Excerpts from Andreas Jaeger's message of 2018-05-01 21:51:19 +0200:
>  On 05/01/2018 04:08 PM, Doug Hellmann wrote:
> > The TC has had an item on our backlog for a while (a year?) to
> > document "constellations" of OpenStack components to make it easier
> > for deployers and users to understand which parts they need to have
> > the features they want [1].
> >
> > John Garbutt has started writing the first such document [2], but
> > as we talked about the content we agreed the TC governance repository
> > is not the best home for it, so I have proposed creating a new
> > repository [3].
> >
> > In order to set up the publishing jobs for that repo so the content
> > goes to docs.openstack.org, we need to settle the ownership of the
> > repository.
> >
> > I think it makes sense for the documentation team to "own" it, but
> > I also think it makes sense for it to have its own review team
> > because it's a bit different from the rest of the docs and we may
> > be able to recruit folks to help who might not want to commit to
> > being core reviewers for all of the documentation repositories. The
> > TC members would also like to be reviewers, to get things going.
> >
> > So, is the documentation team willing to add the new "constellations"
> > repository under their umbrella? Or should we keep it as a TC-owned
> > repository for now?
> 
>  I'm fine having it as parts of the docs team. The docs PTL should be
>  part of the review team for sure,
> 
>  Andreas
> >>>
> >>> Yeah, I wasn't really clear there: I intend to set up the documentation
> >>> and TC teams as members of the new team, so that all members of both
> >>> groups can be reviewers of the new repository.
> >>
> >> +1. What would be the reviewer criteria? Majority vote for adding new 
> >> constellations and 2x +2 for changes maybe? Or just 2x +2 for 
> >> everything? Just to clarify, since the TC reviews usually operate pretty 
> >> differently to other code reviews.
> >>
> >> thanks,
> >> ZB
> >>
> > 
> > This is just documentation, so 2x +2 is what I had in mind.
> > 
> > Doug
> > 
> 
> Is it just docs though? I thought the the point of constellations
> was for a curated set of projects per use case?

The point of constellations is to help users find the components
they need to achieve their goals, by giving them smaller versions
of the OpenStack component map to navigate. It's the sort of thing
a product management group would produce as part of the product
documentation, if we had such a group.

If someone disagrees strongly about the components of a particular
constellation, some items can be listed as alternatives or a
completely separate constellation can be created to support the
different use case. Neither solution requires the TC to, as an
overall governing body, make a decision on for the entire community
using our most strict consensus model for voting.

If we set it up in a way that only the TC can make decisions about
the contents of constellations, then we'll never produce a useful
number of them.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Zun] Announce change of Zun core reviewer team

[Hongbin Lu]

 Hi all,

I would like to announce the following change on the Zun core reviewers
team:

+ Ji Wei

Ji Wei has been working on Zun for a while. His contributions include
blueprints, bug fixes, code reviews, etc. In particular, I would like to
highlight that he has implemented two blueprints [1][2], both of which are
not easy to implement. Based on his high-quality work in the past, I
believe he will serve the core reviewer role very well.

This proposal had been voted within the existing core team and was
unanimously approved. Welcome to the core team Ji Wei.

[1] https://blueprints.launchpad.net/zun/+spec/glance-support-tag
[2] https://blueprints.launchpad.net/zun/+spec/zun-rebuild-on-local-node

Best regards,
Hongbin
__
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] Problems with all OpenStack APIs & uwsgi with Content-Lenght and connection reset by peer (ie: 104)

[Erik Olof Gunnar Andersson]

I noticed something similar when deploying Keystone using nginx in the lab, and 
pretty sure I fixed it by setting  uwsgi_ignore_client_abort to on.
http://nginx.org/en/docs/http/ngx_http_uwsgi_module.html

In addition to that flag I also have
client_header_buffer_size 64k;

uwsgi_buffer_size 8k;
uwsgi_read_timeout600;
uwsgi_send_timeout600;

Best Regards, Erik Olof Gunnar Andersson

-Original Message-
From: Thomas Goirand  
Sent: Wednesday, May 2, 2018 11:28 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] Problems with all OpenStack APIs & uwsgi with 
Content-Lenght and connection reset by peer (ie: 104)

On 05/02/2018 10:25 AM, Chris Dent wrote:
> On Wed, 2 May 2018, Thomas Goirand wrote:
> 
>> What was disturbing was that, doing the same request with curl worked 
>> perfectly. Even more disturbing, it looked like I was having the 
>> issue nearly always in virtualbox, but not always in real hardware, 
>> where it sometimes worked.
> 
> What was making the request in the first place? It fails in X, but 
> works in curl. What is X?

For example, nova-compute querying nova-placement-api.
Another example: openstackclient. It happened to me trying to configure 
keystone when running puppet-openstack, for example, but on the command line 
directly as well, simply trying to add users, projects, etc. This looks like to 
me as a general problem in all of the OpenStack WSGI applications.

>> Anyway, finally, I figured out that adding:
>>
>> --rem-header Content-Lenght
> 
> You added this arg to what?

As a parameter to uwsgi, so that it removes the Content-Lenght that the WSGI 
application sends.

>> This however, looks like a workaround rather than a fix, and I wonder 
>> if there's a real issue somewhere that needs to be fixed in a better 
>> way, maybe in openstackclient or some other component...
> 
> Yeah, it sounds like something could be setting a bad value for the 
> content length header and uwsgi is timing out while trying to read 
> that much data (meaning, it is believing the content-length header) 
> but there isn't anything actually there.
> 
> Another option is that there are buffer size problems in the uwsgi 
> configuration but it's hard to speculate because it is not clear what 
> requests and tools you're actually talking about here.

When attempting to google for the issue, I saw a lot of people that had this 
problem fixed by adding --buffer-size 65535, as the default 4k header of uwsgi 
was not enough. I also have this option set, as it seems a reasonable thing to 
have, but that was not enough to fix the problem.
Only the --rem-header thing did.

If you want to try, you can simply use the stretch-queens.debian.net repository 
with Glance (or simply Debian Sid), and edit /etc/glance/glance-api-wsgi.ini to 
change the uwsgi parameters (I've just switched Glance to uwsgi, since it now 
works...). I haven't checked with Glance, but since I saw the problem with 
nova-placement-api, cinder-api and keystone, I don't see why it wouldn't happen 
there.

Cheers,

Thomas Goirand (zigo)

__
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] Zuul memory improvements

[Jimmy McArthur]

Congrats on the improvements, Jim! Sounds like this is going to make a 
huge difference.  Go Zuul!


Cheers,
Jimmy




James E. Blair 
April 30, 2018 at 10:03 AM
Hi,

We recently made some changes to Zuul which you may want to know about
if you interact with a large number of projects.

Previously, each change to Zuul which updated Zuul's configuration
(e.g., a change to a project's zuul.yaml file) would consume a
significant amount of memory. If we had too many of these in the queue
at a time, the server would run out of RAM. To mitigate this, we asked
folks who regularly submit large numbers of configuration changes to
only submit a few at a time.

We have updated Zuul so it now caches much more of its configuration,
and the cost in memory of an additional configuration change is very
small. An added bonus: they are computed more quickly as well.

Of course, there's still a cost to every change pushed up to Gerrit --
each one uses test nodes, for instance, so if you need to make a large
number of changes, please do consider the impact to the whole system and
other users. However, there's no longer a need to severely restrict
configuration changes as a class -- consider them as any other change.

-Jim

__
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][docs] documenting openstack "constellations"

[Graham Hayes]

On 02/05/18 20:11, Doug Hellmann wrote:
> Excerpts from Zane Bitter's message of 2018-05-02 11:38:55 -0400:
>> On 01/05/18 16:21, Doug Hellmann wrote:
>>> Excerpts from Andreas Jaeger's message of 2018-05-01 21:51:19 +0200:
 On 05/01/2018 04:08 PM, Doug Hellmann wrote:
> The TC has had an item on our backlog for a while (a year?) to
> document "constellations" of OpenStack components to make it easier
> for deployers and users to understand which parts they need to have
> the features they want [1].
>
> John Garbutt has started writing the first such document [2], but
> as we talked about the content we agreed the TC governance repository
> is not the best home for it, so I have proposed creating a new
> repository [3].
>
> In order to set up the publishing jobs for that repo so the content
> goes to docs.openstack.org, we need to settle the ownership of the
> repository.
>
> I think it makes sense for the documentation team to "own" it, but
> I also think it makes sense for it to have its own review team
> because it's a bit different from the rest of the docs and we may
> be able to recruit folks to help who might not want to commit to
> being core reviewers for all of the documentation repositories. The
> TC members would also like to be reviewers, to get things going.
>
> So, is the documentation team willing to add the new "constellations"
> repository under their umbrella? Or should we keep it as a TC-owned
> repository for now?

 I'm fine having it as parts of the docs team. The docs PTL should be
 part of the review team for sure,

 Andreas
>>>
>>> Yeah, I wasn't really clear there: I intend to set up the documentation
>>> and TC teams as members of the new team, so that all members of both
>>> groups can be reviewers of the new repository.
>>
>> +1. What would be the reviewer criteria? Majority vote for adding new 
>> constellations and 2x +2 for changes maybe? Or just 2x +2 for 
>> everything? Just to clarify, since the TC reviews usually operate pretty 
>> differently to other code reviews.
>>
>> thanks,
>> ZB
>>
> 
> This is just documentation, so 2x +2 is what I had in mind.
> 
> Doug
> 

Is it just docs though? I thought the the point of constellations
was for a curated set of projects per use case?



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][docs] documenting openstack "constellations"

[Doug Hellmann]

Excerpts from Petr Kovar's message of 2018-05-02 15:56:36 +0200:
> On Tue, 01 May 2018 10:08:23 -0400
> Doug Hellmann  wrote:
> 
> > The TC has had an item on our backlog for a while (a year?) to
> > document "constellations" of OpenStack components to make it easier
> > for deployers and users to understand which parts they need to have
> > the features they want [1].
> > 
> > John Garbutt has started writing the first such document [2], but
> > as we talked about the content we agreed the TC governance repository
> > is not the best home for it, so I have proposed creating a new
> > repository [3].
> > 
> > In order to set up the publishing jobs for that repo so the content
> > goes to docs.openstack.org, we need to settle the ownership of the
> > repository.
> > 
> > I think it makes sense for the documentation team to "own" it, but
> > I also think it makes sense for it to have its own review team
> > because it's a bit different from the rest of the docs and we may
> > be able to recruit folks to help who might not want to commit to
> > being core reviewers for all of the documentation repositories. The
> > TC members would also like to be reviewers, to get things going.
> > 
> > So, is the documentation team willing to add the new "constellations"
> > repository under their umbrella?
> 
> Fine with me and thanks for bringing this up!
> 
> From the top of my head, this will also require updating the doc contrib
> guide and the docs review dashboard.
> 
> https://docs.openstack.org/doc-contrib-guide/team-structure.html
> https://is.gd/openstackdocsdashboard
> 
> Thanks,
> pk
> 

Thanks, Petr.

I will make a note of that and look for a volunteer to take care of it.

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

Re: [openstack-dev] [tc][docs] documenting openstack "constellations"

[Doug Hellmann]

Excerpts from Zane Bitter's message of 2018-05-02 11:38:55 -0400:
> On 01/05/18 16:21, Doug Hellmann wrote:
> > Excerpts from Andreas Jaeger's message of 2018-05-01 21:51:19 +0200:
> >> On 05/01/2018 04:08 PM, Doug Hellmann wrote:
> >>> The TC has had an item on our backlog for a while (a year?) to
> >>> document "constellations" of OpenStack components to make it easier
> >>> for deployers and users to understand which parts they need to have
> >>> the features they want [1].
> >>>
> >>> John Garbutt has started writing the first such document [2], but
> >>> as we talked about the content we agreed the TC governance repository
> >>> is not the best home for it, so I have proposed creating a new
> >>> repository [3].
> >>>
> >>> In order to set up the publishing jobs for that repo so the content
> >>> goes to docs.openstack.org, we need to settle the ownership of the
> >>> repository.
> >>>
> >>> I think it makes sense for the documentation team to "own" it, but
> >>> I also think it makes sense for it to have its own review team
> >>> because it's a bit different from the rest of the docs and we may
> >>> be able to recruit folks to help who might not want to commit to
> >>> being core reviewers for all of the documentation repositories. The
> >>> TC members would also like to be reviewers, to get things going.
> >>>
> >>> So, is the documentation team willing to add the new "constellations"
> >>> repository under their umbrella? Or should we keep it as a TC-owned
> >>> repository for now?
> >>
> >> I'm fine having it as parts of the docs team. The docs PTL should be
> >> part of the review team for sure,
> >>
> >> Andreas
> > 
> > Yeah, I wasn't really clear there: I intend to set up the documentation
> > and TC teams as members of the new team, so that all members of both
> > groups can be reviewers of the new repository.
> 
> +1. What would be the reviewer criteria? Majority vote for adding new 
> constellations and 2x +2 for changes maybe? Or just 2x +2 for 
> everything? Just to clarify, since the TC reviews usually operate pretty 
> differently to other code reviews.
> 
> thanks,
> ZB
> 

This is just documentation, so 2x +2 is what I had in mind.

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

Re: [openstack-dev] [openstack-ansible] Implement rotations for meetings handling

[Doug Hellmann]

Excerpts from Jean-Philippe Evrard's message of 2018-05-02 17:14:07 +0200:
> Hello everyone,
> 
> Now that we are all part-time, I'd like to toy with a new idea,
> proposed in the past by Jesse, to rotate the duties with people who
> are involved in OSA, or want to get involved more (it's not restricted
> to core developers!).
> 
> One of the first duties to be handled this way could be the weekly meeting.
> 
> Handling the meeting is not that hard, it just takes time to prepare,
> and to facilitate.
> 
> I think everyone should step into this, not only core developers, but
> core developers are now expected to run the meetings when their turn
> comes.
> 
> 
> What are the actions to take:
> - Prepare the triage. Generate the list of the bugs for the week.
> - Ping people with the triage links around 1h before the weekly
> meeting. It would give them time to get prepared for meeting,
> eventually updating the agenda, and read the current bugs
> - Ping people at the beginning of the meeting
> - Chair the meeting: The structure of the meeting is now always
> the same, a recap of the week, and handling the bug triage.
> - After the meeting we would ask who is volunteer to run next
> meeting, and if none, a meeting char will be selected amongst core
> contributors at random.
> 
> Thank you for your understanding.
> 
> Jean-Philippe Evrard (evrardjp)
> 

This is a great idea for sharing the load of organizing the team!

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

Re: [openstack-dev] Problems with all OpenStack APIs & uwsgi with Content-Lenght and connection reset by peer (ie: 104)

[Thomas Goirand]

On 05/02/2018 10:25 AM, Chris Dent wrote:
> On Wed, 2 May 2018, Thomas Goirand wrote:
> 
>> What was disturbing was that, doing the same request with curl worked
>> perfectly. Even more disturbing, it looked like I was having the issue
>> nearly always in virtualbox, but not always in real hardware, where it
>> sometimes worked.
> 
> What was making the request in the first place? It fails in X, but
> works in curl. What is X?

For example, nova-compute querying nova-placement-api.
Another example: openstackclient. It happened to me trying to configure
keystone when running puppet-openstack, for example, but on the command
line directly as well, simply trying to add users, projects, etc. This
looks like to me as a general problem in all of the OpenStack WSGI
applications.

>> Anyway, finally, I figured out that adding:
>>
>> --rem-header Content-Lenght
> 
> You added this arg to what?

As a parameter to uwsgi, so that it removes the Content-Lenght that the
WSGI application sends.

>> This however, looks like a workaround rather than a fix, and I wonder if
>> there's a real issue somewhere that needs to be fixed in a better way,
>> maybe in openstackclient or some other component...
> 
> Yeah, it sounds like something could be setting a bad value for the
> content length header and uwsgi is timing out while trying to read
> that much data (meaning, it is believing the content-length header)
> but there isn't anything actually there.
> 
> Another option is that there are buffer size problems in the uwsgi
> configuration but it's hard to speculate because it is not clear
> what requests and tools you're actually talking about here.

When attempting to google for the issue, I saw a lot of people that had
this problem fixed by adding --buffer-size 65535, as the default 4k
header of uwsgi was not enough. I also have this option set, as it seems
a reasonable thing to have, but that was not enough to fix the problem.
Only the --rem-header thing did.

If you want to try, you can simply use the stretch-queens.debian.net
repository with Glance (or simply Debian Sid), and edit
/etc/glance/glance-api-wsgi.ini to change the uwsgi parameters (I've
just switched Glance to uwsgi, since it now works...). I haven't checked
with Glance, but since I saw the problem with nova-placement-api,
cinder-api and keystone, I don't see why it wouldn't happen there.

Cheers,

Thomas Goirand (zigo)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ironic] ironic_host_manager and baremetal scheduler options removal

[Mathieu Gagné]

On Wed, May 2, 2018 at 1:39 PM, Matt Riedemann  wrote:
>
> I know you're just one case, but I don't know how many people are really
> running the CachingScheduler with ironic either, so it might be rare. It
> would be nice to get other operator input here, like I'm guessing CERN has
> their cells carved up so that certain cells are only serving baremetal
> requests while other cells are only VMs?

I found FilterScheduler to be near impossible to use with Ironic due
to the huge number of hypervisors it had to handle.
Using CachingScheduler made a huge difference, like day and night.

> FWIW, I think we can also backport the data migration CLI to stable branches
> once we have it available so you can do your migration in let's say Queens
> before getting to Rocky.

--
Mathieu

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ironic] ironic_host_manager and baremetal scheduler options removal

[Matt Riedemann]

On 5/2/2018 12:00 PM, Mathieu Gagné wrote:

If one can still run CachingScheduler (even if it's deprecated), I
think we shouldn't remove the above options.
As you can end up with a broken setup and IIUC no way to migrate to
placement since migration script has yet to be written.


You're currently on cells v1 on mitaka right? So you have some time to 
get this sorted out before getting to Rocky where the IronicHostManager 
is dropped.


I know you're just one case, but I don't know how many people are really 
running the CachingScheduler with ironic either, so it might be rare. It 
would be nice to get other operator input here, like I'm guessing CERN 
has their cells carved up so that certain cells are only serving 
baremetal requests while other cells are only VMs?


FWIW, I think we can also backport the data migration CLI to stable 
branches once we have it available so you can do your migration in let's 
say Queens before getting to Rocky.


--

Thanks,

Matt

__
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] [tripleo] Third party module commits to TripleO/Newton branch

[Alex Schultz]

On Wed, May 2, 2018 at 10:23 AM, Shyam Biradar
 wrote:
> Hi,
>
> I am working on TrilioVault deployment integration with TripleO.
> This integration will contain changes to TripleO heat templates repo and
> tripleO puppet module as shown in attached document.
>
> We are targeting this integration for OpenStack Newton release first.
> I just wanted to know, if we are allowed to commit new changes which are not
> related to any core components to Newton branch of tripleo heat templates
> repo,
> openstack tripleo repo.
>

No we're looking to shut down the upstream newton repos in the near
future (like this month[0]).  We're only keeping it open at this point
for fast-forward upgrade type of issues. You would need to work on
master and backport as far as available and downstream the rest.

Thanks,
-Alex

[0] 
http://eavesdrop.openstack.org/meetings/tripleo/2018/tripleo.2018-05-01-14.00.log.html#l-164

>
>
> Thanks & Regards,
> Shyam Biradar,
> Email: shyambiradarsgg...@gmail.com,
> Contact: +91 8600266938.
>
> __
> 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] [openstack-ansible] Implement rotations for meetings handling

[Jimmy McCrory]

+1 good idea

On Wed, May 2, 2018 at 9:09 AM, Amy Marrich  wrote:

> +1, leading meetings is a great way to get folks involved in the Community
> and gives them some 'ownership' within the project.
>
> Amy (spotz)
>
> On Wed, May 2, 2018 at 10:14 AM, Jean-Philippe Evrard <
> jean-phili...@evrard.me> wrote:
>
>> Hello everyone,
>>
>> Now that we are all part-time, I'd like to toy with a new idea,
>> proposed in the past by Jesse, to rotate the duties with people who
>> are involved in OSA, or want to get involved more (it's not restricted
>> to core developers!).
>>
>> One of the first duties to be handled this way could be the weekly
>> meeting.
>>
>> Handling the meeting is not that hard, it just takes time to prepare,
>> and to facilitate.
>>
>> I think everyone should step into this, not only core developers, but
>> core developers are now expected to run the meetings when their turn
>> comes.
>>
>>
>> What are the actions to take:
>> - Prepare the triage. Generate the list of the bugs for the week.
>> - Ping people with the triage links around 1h before the weekly
>> meeting. It would give them time to get prepared for meeting,
>> eventually updating the agenda, and read the current bugs
>> - Ping people at the beginning of the meeting
>> - Chair the meeting: The structure of the meeting is now always
>> the same, a recap of the week, and handling the bug triage.
>> - After the meeting we would ask who is volunteer to run next
>> meeting, and if none, a meeting char will be selected amongst core
>> contributors at random.
>>
>> Thank you for your understanding.
>>
>> Jean-Philippe Evrard (evrardjp)
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ironic] ironic_host_manager and baremetal scheduler options removal

[Mathieu Gagné]

On Wed, May 2, 2018 at 12:49 PM, Matt Riedemann  wrote:
> On 5/2/2018 11:40 AM, Mathieu Gagné wrote:
>>
>> What's the state of caching_scheduler which could still be using those
>> configs?
>
>
> The CachingScheduler has been deprecated since Pike [1]. We discussed the
> CachingScheduler at the Rocky PTG in Dublin [2] and have a TODO to write a
> nova-manage data migration tool to create allocations in Placement for
> instances that were scheduled using the CachingScheduler (since Pike) which
> don't have their own resource allocations set in Placement (remember that
> starting in Pike the FilterScheduler started creating allocations in
> Placement rather than the ResourceTracker in nova-compute).
>
> If you're running computes that are Ocata or Newton, then the
> ResourceTracker in the nova-compute service should be creating the
> allocations in Placement for you, assuming you have the compute service
> configured to talk to Placement (optional in Newton, required in Ocata).
>
> [1] https://review.openstack.org/#/c/492210/
> [2] https://etherpad.openstack.org/p/nova-ptg-rocky-placement

If one can still run CachingScheduler (even if it's deprecated), I
think we shouldn't remove the above options.
As you can end up with a broken setup and IIUC no way to migrate to
placement since migration script has yet to be written.

--
Mathieu

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ironic] ironic_host_manager and baremetal scheduler options removal

[Matt Riedemann]

On 5/2/2018 11:40 AM, Mathieu Gagné wrote:

What's the state of caching_scheduler which could still be using those configs?


The CachingScheduler has been deprecated since Pike [1]. We discussed 
the CachingScheduler at the Rocky PTG in Dublin [2] and have a TODO to 
write a nova-manage data migration tool to create allocations in 
Placement for instances that were scheduled using the CachingScheduler 
(since Pike) which don't have their own resource allocations set in 
Placement (remember that starting in Pike the FilterScheduler started 
creating allocations in Placement rather than the ResourceTracker in 
nova-compute).


If you're running computes that are Ocata or Newton, then the 
ResourceTracker in the nova-compute service should be creating the 
allocations in Placement for you, assuming you have the compute service 
configured to talk to Placement (optional in Newton, required in Ocata).


[1] https://review.openstack.org/#/c/492210/
[2] https://etherpad.openstack.org/p/nova-ptg-rocky-placement

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ironic] ironic_host_manager and baremetal scheduler options removal

[Mathieu Gagné]

What's the state of caching_scheduler which could still be using those configs?

Mathieu

On Wed, May 2, 2018 at 12:25 PM, Matt Riedemann  wrote:
> The baremetal scheduling options were deprecated in Pike [1] and the
> ironic_host_manager was deprecated in Queens [2] and is now being removed
> [3]. Deployments must use resource classes now for baremetal scheduling. [4]
>
> The large host subset size value is also no longer needed. [5]
>
> I've gone through all of the references to "ironic_host_manager" that I
> could find in codesearch.o.o and updated projects accordingly [6].
>
> Please reply ASAP to this thread and/or [3] if you have issues with this.
>
> [1] https://review.openstack.org/#/c/493052/
> [2] https://review.openstack.org/#/c/521648/
> [3] https://review.openstack.org/#/c/565805/
> [4]
> https://docs.openstack.org/ironic/latest/install/configure-nova-flavors.html#scheduling-based-on-resource-classes
> [5] https://review.openstack.org/565736/
> [6]
> https://review.openstack.org/#/q/topic:exact-filters+(status:open+OR+status:merged)
>

__
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] Third party module commits to TripleO/Newton branch

[Matt Riedemann]

On 5/2/2018 11:23 AM, Shyam Biradar wrote:
I am working on TrilioVault  
deployment integration with TripleO.
This integration will contain changes to TripleO heat templates repo and 
tripleO puppet module as shown in attached document.


We are targeting this integration for OpenStack Newton release first.
I just wanted to know, if we are allowed to commit new changes which are 
not related to any core components to Newton branch of tripleo heat 
templates  repo,

openstack tripleo repo .


Why wouldn't you start on master, or queens, and then move backward to 
the older branches?


--

Thanks,

Matt

__
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] [nova][ironic] ironic_host_manager and baremetal scheduler options removal

[Matt Riedemann]

The baremetal scheduling options were deprecated in Pike [1] and the 
ironic_host_manager was deprecated in Queens [2] and is now being 
removed [3]. Deployments must use resource classes now for baremetal 
scheduling. [4]


The large host subset size value is also no longer needed. [5]

I've gone through all of the references to "ironic_host_manager" that I 
could find in codesearch.o.o and updated projects accordingly [6].


Please reply ASAP to this thread and/or [3] if you have issues with this.

[1] https://review.openstack.org/#/c/493052/
[2] https://review.openstack.org/#/c/521648/
[3] https://review.openstack.org/#/c/565805/
[4] 
https://docs.openstack.org/ironic/latest/install/configure-nova-flavors.html#scheduling-based-on-resource-classes

[5] https://review.openstack.org/565736/
[6] 
https://review.openstack.org/#/q/topic:exact-filters+(status:open+OR+status:merged)


--

Thanks,

Matt

__
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] Third party module commits to TripleO/Newton branch

[Shyam Biradar]

Hi,

I am working on TrilioVault  deployment
integration with TripleO.
This integration will contain changes to TripleO heat templates repo and
tripleO puppet module as shown in attached document.

We are targeting this integration for OpenStack Newton release first.
I just wanted to know, if we are allowed to commit new changes which are
not related to any core components to Newton branch of tripleo heat
templates  repo,
openstack tripleo repo .



Thanks & Regards,
Shyam Biradar,
Email: shyambiradarsgg...@gmail.com,
Contact: +91 8600266938.


Trilio_RedhatDirector_Integration.pdf
Description: Adobe PDF document
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Arvind N]

 > What if the API compares the original image required traits against the
new image required traits, and if the new image has required traits which
weren't in the original image, then (punt) fail in the API? Then you would
at least have a chance > to rebuild with a new image that has required
traits as long as those required traits are less than or equal to the
originally validated traits for the host on which the instance is currently
running.

This is what i was proposing with #1, sorry if it was unclear. Will make it
more explicit.

1. Reject the rebuild request indicating that rebuilding with a new image
with **different** required traits compared to the original request is not
supported.
If the new image has the same or reduced set of traits as the old image,
then the request will be passed through to the conductor etc

Pseudo code

> if  not set(new_image.traits_required).issubset(
set(original_image.traits_required))
>  raise exception

On Wed, May 2, 2018 at 7:07 AM, Matt Riedemann  wrote:

> On 5/1/2018 5:26 PM, Arvind N wrote:
>
>> In cases of rebuilding of an instance using a different image where the
>> image traits have changed between the original launch and the rebuild, is
>> it reasonable to ask to just re-launch a new instance with the new image?
>>
>> The argument for this approach is that given that the requirements have
>> changed, we want the scheduler to pick and allocate the appropriate host
>> for the instance.
>>
>
> We don't know if the requirements have changed with the new image until we
> check them.
>
> Here is another option:
>
> What if the API compares the original image required traits against the
> new image required traits, and if the new image has required traits which
> weren't in the original image, then (punt) fail in the API? Then you would
> at least have a chance to rebuild with a new image that has required traits
> as long as those required traits are less than or equal to the originally
> validated traits for the host on which the instance is currently running.
>
>
>> The approach above also gives you consistent results vs the other
>> approaches where the rebuild may or may not succeed depending on how the
>> original allocation of resources went.
>>
>>
> Consistently frustrating, I agree. :) Because as a user, I can rebuild
> with some images (that don't have required traits) and can't rebuild with
> other images (that do have required traits).
>
> I see no difference with this and being able to rebuild (with a new image)
> some instances (image-backed) and not others (volume-backed). Given that, I
> expect if we punt on this, someone will just come along asking for the
> support later. Could be a couple of years from now when everyone has moved
> on and it then becomes someone else's problem.
>
> For example(from Alex Xu) ,if you launched an instance on a host which has
>> two SRIOV nic. One is normal SRIOV nic(A), another one with some kind of
>> offload feature(B).
>>
>> So, the original request is: resources=SRIOV_VF:1 The instance gets a VF
>> from the normal SRIOV nic(A).
>>
>> But with a new image, the new request is: resources=SRIOV_VF:1
>> traits=HW_NIC_OFFLOAD_XX
>>
>> With all the solutions discussed in the thread, a rebuild request like
>> above may or may not succeed depending on whether during the initial launch
>> whether nic A or nic B was allocated.
>>
>> Remember that in rebuild new allocation don't happen, we have to reuse
>> the existing allocations.
>>
>> Given the above background, there seems to be 2 competing options.
>>
>> 1. Fail in the API saying you can't rebuild with a new image with new
>> required traits.
>>
>> 2. Look at the current allocations for the instance and try to match the
>> new requirement from the image with the allocations.
>>
>> With #1, we get consistent results in regards to how rebuilds are treated
>> when the image traits changed.
>>
>> With #2, the rebuild may or may not succeed, depending on how well the
>> original allocations match up with the new requirements.
>>
>> #2 will also need to need to account for handling preferred traits or
>> granular resource traits if we decide to implement them for images at some
>> point...
>>
>
> Option 10: Don't support image-defined traits at all. I know that won't
> happen though.
>
> At this point I'm exhausted with this entire issue and conversation and
> will probably bow out and need someone else to step in with different
> perspective, like melwitt or dansmith.
>
> All of the solutions are bad in their own way, either because they add
> technical debt and poor user experience, or because they make rebuild more
> complicated and harder to maintain for the developers.
>
> --
>
> Thanks,
>
> Matt
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [openstack-ansible] Implement rotations for meetings handling

[Amy Marrich]

+1, leading meetings is a great way to get folks involved in the Community
and gives them some 'ownership' within the project.

Amy (spotz)

On Wed, May 2, 2018 at 10:14 AM, Jean-Philippe Evrard <
jean-phili...@evrard.me> wrote:

> Hello everyone,
>
> Now that we are all part-time, I'd like to toy with a new idea,
> proposed in the past by Jesse, to rotate the duties with people who
> are involved in OSA, or want to get involved more (it's not restricted
> to core developers!).
>
> One of the first duties to be handled this way could be the weekly meeting.
>
> Handling the meeting is not that hard, it just takes time to prepare,
> and to facilitate.
>
> I think everyone should step into this, not only core developers, but
> core developers are now expected to run the meetings when their turn
> comes.
>
>
> What are the actions to take:
> - Prepare the triage. Generate the list of the bugs for the week.
> - Ping people with the triage links around 1h before the weekly
> meeting. It would give them time to get prepared for meeting,
> eventually updating the agenda, and read the current bugs
> - Ping people at the beginning of the meeting
> - Chair the meeting: The structure of the meeting is now always
> the same, a recap of the week, and handling the bug triage.
> - After the meeting we would ask who is volunteer to run next
> meeting, and if none, a meeting char will be selected amongst core
> contributors at random.
>
> Thank you for your understanding.
>
> Jean-Philippe Evrard (evrardjp)
>
> __
> 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] [openstack-ansible] Implement rotations for meetings handling

[David Wilde]

I am definitely +1 on this, I think it's a great idea.

Thanks,

Dave Wilde (d34dh0r53)

On Wed, May 2, 2018 at 10:27 AM Mohammed Naser  wrote:

> On Wed, May 2, 2018 at 11:14 AM, Jean-Philippe Evrard
>  wrote:
> > Hello everyone,
> >
> > Now that we are all part-time, I'd like to toy with a new idea,
> > proposed in the past by Jesse, to rotate the duties with people who
> > are involved in OSA, or want to get involved more (it's not restricted
> > to core developers!).
> >
> > One of the first duties to be handled this way could be the weekly
> meeting.
>
> +1
>
> I think that's something that we can share amongst us as a responsibility
> and
> take turns doing.
>
> > Handling the meeting is not that hard, it just takes time to prepare,
> > and to facilitate.
> >
> > I think everyone should step into this, not only core developers, but
> > core developers are now expected to run the meetings when their turn
> > comes.
> >
> >
> > What are the actions to take:
> > - Prepare the triage. Generate the list of the bugs for the week.
> > - Ping people with the triage links around 1h before the weekly
> > meeting. It would give them time to get prepared for meeting,
> > eventually updating the agenda, and read the current bugs
> > - Ping people at the beginning of the meeting
> > - Chair the meeting: The structure of the meeting is now always
> > the same, a recap of the week, and handling the bug triage.
> > - After the meeting we would ask who is volunteer to run next
> > meeting, and if none, a meeting char will be selected amongst core
> > contributors at random.
> >
> > Thank you for your understanding.
> >
> > Jean-Philippe Evrard (evrardjp)
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][docs] documenting openstack "constellations"

[Zane Bitter]

On 01/05/18 16:21, Doug Hellmann wrote:

Excerpts from Andreas Jaeger's message of 2018-05-01 21:51:19 +0200:

On 05/01/2018 04:08 PM, Doug Hellmann wrote:

The TC has had an item on our backlog for a while (a year?) to
document "constellations" of OpenStack components to make it easier
for deployers and users to understand which parts they need to have
the features they want [1].

John Garbutt has started writing the first such document [2], but
as we talked about the content we agreed the TC governance repository
is not the best home for it, so I have proposed creating a new
repository [3].

In order to set up the publishing jobs for that repo so the content
goes to docs.openstack.org, we need to settle the ownership of the
repository.

I think it makes sense for the documentation team to "own" it, but
I also think it makes sense for it to have its own review team
because it's a bit different from the rest of the docs and we may
be able to recruit folks to help who might not want to commit to
being core reviewers for all of the documentation repositories. The
TC members would also like to be reviewers, to get things going.

So, is the documentation team willing to add the new "constellations"
repository under their umbrella? Or should we keep it as a TC-owned
repository for now?


I'm fine having it as parts of the docs team. The docs PTL should be
part of the review team for sure,

Andreas


Yeah, I wasn't really clear there: I intend to set up the documentation
and TC teams as members of the new team, so that all members of both
groups can be reviewers of the new repository.


+1. What would be the reviewer criteria? Majority vote for adding new 
constellations and 2x +2 for changes maybe? Or just 2x +2 for 
everything? Just to clarify, since the TC reviews usually operate pretty 
differently to other code reviews.


thanks,
ZB

__
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-ansible] Implement rotations for meetings handling

[Mohammed Naser]

On Wed, May 2, 2018 at 11:14 AM, Jean-Philippe Evrard
 wrote:
> Hello everyone,
>
> Now that we are all part-time, I'd like to toy with a new idea,
> proposed in the past by Jesse, to rotate the duties with people who
> are involved in OSA, or want to get involved more (it's not restricted
> to core developers!).
>
> One of the first duties to be handled this way could be the weekly meeting.

+1

I think that's something that we can share amongst us as a responsibility and
take turns doing.

> Handling the meeting is not that hard, it just takes time to prepare,
> and to facilitate.
>
> I think everyone should step into this, not only core developers, but
> core developers are now expected to run the meetings when their turn
> comes.
>
>
> What are the actions to take:
> - Prepare the triage. Generate the list of the bugs for the week.
> - Ping people with the triage links around 1h before the weekly
> meeting. It would give them time to get prepared for meeting,
> eventually updating the agenda, and read the current bugs
> - Ping people at the beginning of the meeting
> - Chair the meeting: The structure of the meeting is now always
> the same, a recap of the week, and handling the bug triage.
> - After the meeting we would ask who is volunteer to run next
> meeting, and if none, a meeting char will be selected amongst core
> contributors at random.
>
> Thank you for your understanding.
>
> Jean-Philippe Evrard (evrardjp)
>
> __
> 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] [openstack-ansible] Implement rotations for meetings handling

[Jean-Philippe Evrard]

Hello everyone,

Now that we are all part-time, I'd like to toy with a new idea,
proposed in the past by Jesse, to rotate the duties with people who
are involved in OSA, or want to get involved more (it's not restricted
to core developers!).

One of the first duties to be handled this way could be the weekly meeting.

Handling the meeting is not that hard, it just takes time to prepare,
and to facilitate.

I think everyone should step into this, not only core developers, but
core developers are now expected to run the meetings when their turn
comes.


What are the actions to take:
- Prepare the triage. Generate the list of the bugs for the week.
- Ping people with the triage links around 1h before the weekly
meeting. It would give them time to get prepared for meeting,
eventually updating the agenda, and read the current bugs
- Ping people at the beginning of the meeting
- Chair the meeting: The structure of the meeting is now always
the same, a recap of the week, and handling the bug triage.
- After the meeting we would ask who is volunteer to run next
meeting, and if none, a meeting char will be selected amongst core
contributors at random.

Thank you for your understanding.

Jean-Philippe Evrard (evrardjp)

__
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] Thank you TryStack!!

[Jimmy McArthur]

Just wanted to follow up on this.  trystack.openstack.org is now 
correctly redirecting to the same place as trystack.org.


Thanks,
Jimmy


Jimmy McArthur 
April 30, 2018 at 1:01 PM
OK - got it :)


__
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
Jeremy Stanley 
April 30, 2018 at 12:29 PM
[...]

I was thrown by the fact that DNS currently has
trystack.openstack.org as a CNAME alias for trystack.org, but
reviewing logs on static.openstack.org it seems it may have
previously pointed there (was receiving traffic up until around
13:15 UTC today) so if you want to just glom that onto the current
trystack.org redirect that may make the most sense and we can move
forward tearing down the old infrastructure for it.
__
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 
April 30, 2018 at 12:10 PM
Yeah... my only concern is that if traffic is actually getting there, 
a redirect to the same place trystack.org is going might be helpful.



__
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
Jeremy Stanley 
April 30, 2018 at 12:02 PM
On 2018-04-30 11:07:27 -0500 (-0500), Jimmy McArthur wrote:
[...]
[...]

Since I don't think the trystack.o.o site ever found its way fully
into production, it may make more sense for us to simply delete the
records for it from DNS. Someone else probably knows more about the
prior state of it than I though.
__
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 
April 30, 2018 at 11:07 AM



Jeremy Stanley 
April 30, 2018 at 10:12 AM
[...]

Yes, before the TryStack effort was closed down, there had been a
plan for trystack.org to redirect to a trystack.openstack.org site
hosted in the community infrastructure. 
When we talked to trystack we agreed to redirect trystack.org to 
https://openstack.org/software/start since that presents alternative 
options for people to "try openstack".  My suggestion would be to 
redirect trystack.openstack.org to the same spot, but certainly open 
to other suggestions :)

At this point I expect we
can just rip out the section for it from
https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/static.pp
as DNS appears to no longer be pointed there.
__
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 
April 30, 2018 at 9:34 AM
I'm working on redirecting trystack.openstack.org to 
openstack.org/software/start.  We have redirects in place for 
trystack.org, but didn't realize trystack.openstack.org as a thing as 
well.



__
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
Paul Belanger 
April 30, 2018 at 9:23 AM
The code is hosted by openstack-infra[1], if somebody would like to 
propose a

patch with the new information.

[1] http://git.openstack.org/cgit/openstack-infra/trystack-site

__
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
Jens Harbott 
April 30, 2018 at 4:37 AM

Seems it would be great if https://trystack.openstack.org/ would be
updated with this information, according to comments in #openstack
users are still landing on that page and try to get a stack there in
vain.

__
OpenStack 

Re: [openstack-dev] [keystone] [policy] no policy meeting today

[Harry Rybacki]

Perhaps this meeting would be a good opportunity to get some broader
discussion on our default roles spec we have proposed[1].

[1] - https://review.openstack.org/#/c/523973/8/specs/define-default-roles.rst


/R

Harry

On Wed, May 2, 2018 at 10:17 AM, Lance Bragstad  wrote:
> Hi all,
>
> I'm going to cancel the policy meeting today since attendance has been
> waning the last month or two and there are no items on the agenda.
>
> We should discuss whether or not we want to continue using this meeting.
> At this point, most of the policy work is in helping projects consume
> outcomes from those meetings.The meeting was originally proposed to help
> design a better policy system across OpenStack and figure out how to
> move towards it. If we feel we've come up with a direction that achieves
> that, I'm happy to summarize things and drop the bi-weekly meeting.
> Otherwise, if there are use cases we need to tackle next, we can
> continue holding the meeting.
>
> Thoughts?
>
> Lance
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Gerrit server replacement scheduled for May 2nd 2018

[Paul Belanger]

Hello from Infra.

Today is the day for scheduled maintenance of gerrit, we'll be allocating 2
hours for the outage but don't expect it to take that long. During this time you
will not be able to access gerrit.

If you have any questions, or would like to follow along, please join us in
#openstack-infra.

---

It's that time again... on Wednesday, May 02, 2018 20:00 UTC, the OpenStack
Project Infrastructure team is upgrading the server which runs
review.openstack.org to Ubuntu Xenial, and that means a new virtual machine
instance with new IP addresses assigned by our service provider. The new IP
addresses will be as follows:

IPv4 -> 104.130.246.32
IPv6 -> 2001:4800:7819:103:be76:4eff:fe04:9229

They will replace these current production IP addresses:

IPv4 -> 104.130.246.91
IPv6 -> 2001:4800:7819:103:be76:4eff:fe05:8525

We understand that some users may be running from egress-filtered
networks with port 29418/tcp explicitly allowed to the current
review.openstack.org IP addresses, and so are providing this
information as far in advance as we can to allow them time to update
their firewalls accordingly.

Note that some users dealing with egress filtering may find it
easier to switch their local configuration to use Gerrit's REST API
via HTTPS instead, and the current release of git-review has support
for that workflow as well.
http://lists.openstack.org/pipermail/openstack-dev/2014-September/045385.html

We will follow up with final confirmation in subsequent announcements.

Thanks,
Paul

__
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] Overriding project-templates in Zuul

[James E. Blair]

Joshua Hesketh  writes:

>>
>> I think in actuality, both operations would end up as intersections:
>>
>>     ===  ===
>> Matcher   Template  Project  Result
>>     ===  ===
>> files ABBC   B
>> irrelevant-files  ABBC   B
>>     ===  ===
>>
>> So with the "combine" method, it's always possible to further restrict
>> where the job runs, but never to expand it.
>
> Ignoring the 'files' above, in the example of 'irrelevant-files' haven't
> you just combined the results to expand when it runs? ie, A and C are /not/
> excluded and therefore the job will run when there are changes to A or C?
>
> I would expect the table to be something like:
>     ===  ===
> Matcher   Template  Project  Result
>     ===  ===
> files ABBC   B
> irrelevant-files  ABBC   ABC
>     ===  ===

Sure, we'll go with that.  :)

>> > So a job with "files: tests/" and "irrelevant-files: docs/" would do
>> > whatever it is that happens when you specify both.
>>
>> In this case, I'm pretty sure that would mean it reduces to just "files:
>> tests/", but I've never claimed to understand irrelevant-files and I
>> won't start now.
>
> Yes, I think you are right that this would reduce to that. However, what
> about the use case of:
>   files: tests/*
>   irrelevant-files: tests/docs/*
>
> I could see a use case where both of those would be helpful. Yes you could
> describe that as one regex but to the end user the above may be expected to
> work. Unless we make the two options mutually exclusive I feel like this is
> a feature we should support. (That said, it's likely a separate
> feature/functionality than what is being described now).

Today, that means: run the job if a file in tests/ is changed AND any
file outside of tests/docs/* is changed.  A change to tests/foo matches
the irrelevant-files matcher, and also the files matcher, so it runs.  A
change to tests/docs/foo matches the files matcher but not the
irrelevant-files matcher, so it doesn't run.  I really hope I got that
right.  Anyway, that is an example of something that's possible to
express with both.

I lumped in the idea of pairing files/irrelevant-files with Proposal 2
because I thought that being able to override them is key, and switching
from one to the other was part of that, and, to be honest, I don't think
people should ever combine them because it's hard enough to deal with
one, but maybe that's too much of an implicit behavior change, and
instead we should separate that out and consider it as its own change
later.  I believe a user could still stop a the matchers by saying
"files: .*" and "irrelevant-files: ^$" in the project-local variant.

Let's revise Proposal #2 to omit that:

Proposal 2: Files and irrelevant-files are treated as overwriteable
attributes and evaluated after branch-matching variants are combined.

* Files and irrelevant-files are overwritten, so the last value
  encountered when combining all the matching variants (looking only at
  branches) wins.
* It's possible to both reduce and expand the scope of jobs, but the
  user may need to manually copy values from a parent or other variant
  in order to do so.
* It will no longer be possible to alter a job attribute by adding a
  variant with only a files matcher -- in all cases files and
  irrelevant-files are used solely to determine whether the job is run,
  not to determine whether to apply a variant.

> Anyway, I feel like Proposal #2 is more how I would expect the system to
> behave.
>
> I can see an argument for combining the results (and feel like you could
> evaulate that at the end after combining the branch-matching variants) to
> give something like:
>     ===  ===
> Matcher   Template  Project  Result
>     ===  ===
> files ABBC   ABC
> irrelevant-files  ABBC   ABC
>     ===  ===
>
> However, that gives the user no way to remove a previously listed option.
> Thus overwriting may be the better solution (ie proposal #2 as written)
> unless we want to explore the option of allowing a syntax that says
> "extend" or "overwrite".
>
> Yours in hoping that made sense,
> Josh

As much as anything with irrelevant-files does, yes.  :)

-Jim

__
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] [keystone] [policy] no policy meeting today

[Lance Bragstad]

Hi all,

I'm going to cancel the policy meeting today since attendance has been
waning the last month or two and there are no items on the agenda.

We should discuss whether or not we want to continue using this meeting.
At this point, most of the policy work is in helping projects consume
outcomes from those meetings.The meeting was originally proposed to help
design a better policy system across OpenStack and figure out how to
move towards it. If we feel we've come up with a direction that achieves
that, I'm happy to summarize things and drop the bi-weekly meeting.
Otherwise, if there are use cases we need to tackle next, we can
continue holding the meeting.

Thoughts?

Lance



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Matt Riedemann]

On 5/1/2018 5:26 PM, Arvind N wrote:
In cases of rebuilding of an instance using a different image where the 
image traits have changed between the original launch and the rebuild, 
is it reasonable to ask to just re-launch a new instance with the new image?


The argument for this approach is that given that the requirements have 
changed, we want the scheduler to pick and allocate the appropriate host 
for the instance.


We don't know if the requirements have changed with the new image until 
we check them.


Here is another option:

What if the API compares the original image required traits against the 
new image required traits, and if the new image has required traits 
which weren't in the original image, then (punt) fail in the API? Then 
you would at least have a chance to rebuild with a new image that has 
required traits as long as those required traits are less than or equal 
to the originally validated traits for the host on which the instance is 
currently running.




The approach above also gives you consistent results vs the other 
approaches where the rebuild may or may not succeed depending on how the 
original allocation of resources went.




Consistently frustrating, I agree. :) Because as a user, I can rebuild 
with some images (that don't have required traits) and can't rebuild 
with other images (that do have required traits).


I see no difference with this and being able to rebuild (with a new 
image) some instances (image-backed) and not others (volume-backed). 
Given that, I expect if we punt on this, someone will just come along 
asking for the support later. Could be a couple of years from now when 
everyone has moved on and it then becomes someone else's problem.


For example(from Alex Xu) ,if you launched an instance on a host which 
has two SRIOV nic. One is normal SRIOV nic(A), another one with some 
kind of offload feature(B).


So, the original request is: resources=SRIOV_VF:1 The instance gets a VF 
from the normal SRIOV nic(A).


But with a new image, the new request is: resources=SRIOV_VF:1 
traits=HW_NIC_OFFLOAD_XX


With all the solutions discussed in the thread, a rebuild request like 
above may or may not succeed depending on whether during the initial 
launch whether nic A or nic B was allocated.


Remember that in rebuild new allocation don't happen, we have to reuse 
the existing allocations.


Given the above background, there seems to be 2 competing options.

1. Fail in the API saying you can't rebuild with a new image with new 
required traits.


2. Look at the current allocations for the instance and try to match the 
new requirement from the image with the allocations.


With #1, we get consistent results in regards to how rebuilds are 
treated when the image traits changed.


With #2, the rebuild may or may not succeed, depending on how well the 
original allocations match up with the new requirements.


#2 will also need to need to account for handling preferred traits or 
granular resource traits if we decide to implement them for images at 
some point...


Option 10: Don't support image-defined traits at all. I know that won't 
happen though.


At this point I'm exhausted with this entire issue and conversation and 
will probably bow out and need someone else to step in with different 
perspective, like melwitt or dansmith.


All of the solutions are bad in their own way, either because they add 
technical debt and poor user experience, or because they make rebuild 
more complicated and harder to maintain for the developers.


--

Thanks,

Matt

__
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] [docs] Documentation meeting canceled

[Petr Kovar]

Hi all,

Apologies but have to go offline now so canceling today's docs meeting. 

If you want to talk to the docs team, join #openstack-doc.

Thanks,
pk

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Matt Riedemann]

On 4/24/2018 8:26 AM, Sylvain Bauza wrote:
We also have pre-flight checks for move operations like live and cold 
migrations, and I'd really like to keep all the conditionals in the 
conductor, because it knows better than the scheduler which operation is 
asked.


I'm not sure what "pre-flight checks" we have for cold migration. The 
conductor migrate task asks the scheduler for a host and then casts to 
the destination compute to start the migration.


The conductor live migration task does do some checking on the source 
and dest computes before proceeding, I agree with you there.


> I'm not really happy with adding more in the scheduler about "yeah, 
it's a rebuild, so please do something exceptional"


Agree that building more special rebuild logic into the scheduler isn't 
ideal and hopefully we could resolve this in conductor if possible, 
despite the fact that ImagePropertiesFilter is optional (although I'm 
pretty sure everyone enables it).


--

Thanks,

Matt

__
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][docs] documenting openstack "constellations"

[Petr Kovar]

On Tue, 01 May 2018 10:08:23 -0400
Doug Hellmann  wrote:

> The TC has had an item on our backlog for a while (a year?) to
> document "constellations" of OpenStack components to make it easier
> for deployers and users to understand which parts they need to have
> the features they want [1].
> 
> John Garbutt has started writing the first such document [2], but
> as we talked about the content we agreed the TC governance repository
> is not the best home for it, so I have proposed creating a new
> repository [3].
> 
> In order to set up the publishing jobs for that repo so the content
> goes to docs.openstack.org, we need to settle the ownership of the
> repository.
> 
> I think it makes sense for the documentation team to "own" it, but
> I also think it makes sense for it to have its own review team
> because it's a bit different from the rest of the docs and we may
> be able to recruit folks to help who might not want to commit to
> being core reviewers for all of the documentation repositories. The
> TC members would also like to be reviewers, to get things going.
> 
> So, is the documentation team willing to add the new "constellations"
> repository under their umbrella?

Fine with me and thanks for bringing this up!

From the top of my head, this will also require updating the doc contrib
guide and the docs review dashboard.

https://docs.openstack.org/doc-contrib-guide/team-structure.html
https://is.gd/openstackdocsdashboard

Thanks,
pk

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Matt Riedemann]

On 4/24/2018 3:25 AM, Balázs Gibizer wrote:
The algorithm Eric provided in a previous mail do the filtering for the 
RPs that are part of the instance allocation so that sounds good to me.


Yeah I've been wondering if that solves this VF case.

I think we should not try to adjust allocations during a rebuild. 
Changing the allocation would mean it is not a rebuild any more but a 
resize.


Agree.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Matt Riedemann]

On 4/23/2018 4:51 PM, Arvind N wrote:
For #1, we can make the explanation very clear that we rejected the 
request because the original traits specified in the original image and 
the new traits specified in the new image do not match and hence rebuild 
is not supported.


We don't reject rebuild requests today where you rebuild with a new 
image as long as that new image passes the scheduler filters for the 
host on which the instance is already running. I don't see why we'd just 
immediately fail in the API because the new image has required traits, 
when we have no idea, from the nova-api service, whether or not those 
image-defined required traits are going to match the current host or 
not. That's just adding technical debt to rebuild, like we have for 
rebuilding a volume-backed instance with a new image (you can't do it 
today because it wasn't thought about early enough in the design process).




For #2,

Other Cons:

 1. None of the filters currently make other API requests and my
understanding is we want to avoid reintroducing such a pattern. But
definitely workable solution.


For a rebuild-specific request (which we can determine already), I'm OK 
with this - we're already not calling GET /allocation_candidates in this 
case, so if people are worried about performance, it's just a trade of 
one REST API call for another.



 2. If the user disables the image properties filter, then traits based
filtering will not be run in rebuild case


The user doesn't disable the filter, the operator does, and likely for 
good reason. I don't see a problem with this.




For #3,

Even though it handles the nested provider, there is a potential issue.

Lets say a host with two SRIOV nic. One is normal SRIOV nic(VF1), 
another one with some kind of offload feature(VF2).(Described by alex)


Initial instance launch happens with VF:1 allocated, rebuild launches 
with modified request with traits=HW_NIC_OFFLOAD_X, so basically we want 
the instance to be allocated VF2.


But the original allocation happens against VF1 and since in rebuild the 
original allocations are not changed, we have wrong allocations.


I don't know what to say about this. We shouldn't have any quantitative 
resource allocation changes as a result of a rebuild. This actually 
sounds like a case for option #4 with using GET /allocation_candidates 
and then being able to filter out if rebuliding the instance with the 
new image with new required traits but on the same host would result in 
new allocation requests, and if so, we should fail - but we can (only?) 
determine that via the response from GET /allocation_candidates.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Matt Riedemann]

On 4/23/2018 4:43 PM, Jay Pipes wrote:
How about just having the conductor call GET 
/resource_providers?in_tree==, see if 
there is a result, and if not, don't even call the scheduler at all 
(because conductor would already know there would be a NoValidHost 
returned)?


This makes filtering on image properties required, which is something I 
was pushing back on because the ImagePropertiesFilter today, by design 
of all scheduler filters, is configurable and optional, which is why I 
wanted to add the filtering logic for image-defined required traits into 
the ImagePropertiesFilter itself.


--

Thanks,

Matt

__
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][stackalytics][neutron] neutron-lib not showing as TC-approved project on stackalytics

[Mohammed Naser]

On Wed, May 2, 2018 at 9:16 AM, Boden Russell  wrote:
> Back in 2016 we tagged neutron-lib as a "tc-approved-release" and as a
> result neutron-lib commits/reviews showed up on stackalytics under
> TC-approved Project Types.
>
> However as of recent that's seemed to have changed and neutron-lib
> commits/reviews are no longer showing up [1] even though it appears to
> still be tagged [2] IIUC.
>
> Is neutron-lib not showing up as a TC-approved project in
> stackalytics intentional? If so can some please refer me as to why. If
> not how do we get stackalytics to pick it up again?

I think at the moment, Stackalytics is not in an entirely consistent
state, you'll notice in the header:

"The data is being loaded now and is not complete"

I am going to throw a guess that the data hasn't be fully loaded up
yet to appear, it would probably be good to check back once it's fully
loaded and that header is disappeared.

> Thanks
>
>
> [1]
> http://stackalytics.com/?release=rocky_type=tc:approved-release=commits
> [2]
> https://github.com/openstack/governance/blob/master/reference/projects.yaml#L2065
>
> __
> 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] [tc][stackalytics][neutron] neutron-lib not showing as TC-approved project on stackalytics

[Boden Russell]

Back in 2016 we tagged neutron-lib as a "tc-approved-release" and as a
result neutron-lib commits/reviews showed up on stackalytics under
TC-approved Project Types.

However as of recent that's seemed to have changed and neutron-lib
commits/reviews are no longer showing up [1] even though it appears to
still be tagged [2] IIUC.

Is neutron-lib not showing up as a TC-approved project in
stackalytics intentional? If so can some please refer me as to why. If
not how do we get stackalytics to pick it up again?

Thanks


[1]
http://stackalytics.com/?release=rocky_type=tc:approved-release=commits
[2]
https://github.com/openstack/governance/blob/master/reference/projects.yaml#L2065

__
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-operators] The Forum Schedule is now live

[Emilien Macchi]

On Wed, May 2, 2018 at 5:19 AM, Jimmy McArthur  wrote:
>
> No problem, we have both on the schedule.  I moved the Project Update to
> 11-11:20 so you can have a few minutes before the Onboarding starts at
> 11:50.
>
> https://www.openstack.org/summit/vancouver-2018/summit-sched
> ule/global-search?t=TripleO
>
> Let me know if I can assist further.
>

Everything looks excellent to me now. Thanks for your help!
-- 
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The Forum Schedule is now live

[Gilles Dubreuil]

Jimmy,

Fantastic! Thank you.

Cheers,
Gilles


On 02/05/18 22:25, Jimmy McArthur wrote:

Gilles,

Just responded to the ZenDesk ticket :)

Cheers,
Jimmy


Gilles Dubreuil 
May 2, 2018 at 12:09 AM
Hi Jimmy,

Do you have an update about the API SIG slot?

Thanks,
Gilles





__ 


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 
April 27, 2018 at 11:04 AM
Hello all -

Please take a look here for the posted Forum schedule: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224 
You should also see it update on your Summit App.


Thank you and see you in Vancouver!
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




--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The Forum Schedule is now live

[Jimmy McArthur]

Gilles,

Just responded to the ZenDesk ticket :)

Cheers,
Jimmy


Gilles Dubreuil 
May 2, 2018 at 12:09 AM
Hi Jimmy,

Do you have an update about the API SIG slot?

Thanks,
Gilles





__ 


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 
April 27, 2018 at 11:04 AM
Hello all -

Please take a look here for the posted Forum schedule: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224  
You should also see it update on your Summit App.


Thank you and see you in Vancouver!
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


__
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-operators] The Forum Schedule is now live

[Jimmy McArthur]

Emilien Macchi wrote:
Could we change the title of the slot and actually be a TripleO 
Project Update session?
It would have been great to have the onboarding session but I guess we 
also have 2 other sessions where we'll have occasions to meet:

TripleO Ops and User feedback and TripleO and Ansible integration

If it's possible to still have an onboarding session, awesome 
otherwise it's ok I think we'll deal with it.
No problem, we have both on the schedule.  I moved the Project Update to 
11-11:20 so you can have a few minutes before the Onboarding starts at 
11:50.


https://www.openstack.org/summit/vancouver-2018/summit-schedule/global-search?t=TripleO

Let me know if I can assist further.

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

Re: [openstack-dev] [neutron] How to specify OpenStack version for Zuul tests?

[Jim Rollenhagen]

On Wed, May 2, 2018 at 2:10 AM, Sangho Shin 
wrote:

> Hello,
>
> Is there any way to specify the OpenStack version for Zuul test?
>
> Currently, neteworking-onos project is very outdated, and I need to create
> a stable version for the codes for each OpenStack version
> (Ocata/Pike/Queens).
> Each version of OpenStack has different requirements in particular neutron
> libs, and it seems that Zuul is using the master version of OpenStack for
> testing my codes for Ocata.
>

I think the "override-checkout" variable is what you're looking for. The
ironic-tempest-plugin project runs tests on multiple stable branches, that
config is here[0]. The parent jobs referred to in that file are here[1].

[0]
https://git.openstack.org/cgit/openstack/ironic-tempest-plugin/tree/zuul.d/stable-jobs.yaml
[1] https://git.openstack.org/cgit/openstack/ironic/tree/playbooks/legacy

// jim
__
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] [cyborg]No Team Meeting this Wed

[Zhipeng Huang]

Hi team,

Since I'm traveling to KubeCon this week, let's cancel the weekly meeting
today . You are still more than welcome to raise questions or just chat on
our irc channel :)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

Hi Gilles, folks,

Nice to read such answers, I’m really thrilled by what could goes out from
this discussion.

One last thing regarding the SDK and Broker part of the discussion.

GraphQL and SDK:

Obviously as you noticed it, I was focused on the python-openstacksdk part
of things even if it apply to the autonomous Openstack4j JAVA SDK or any
other SDK for your favorite language.

I do agree with you, GraphQL being a DSL it should in a long (or maybe not
so long depending the adoption rate ;-) ) run replace the REST part of the
SDK, however, I think the client libraries (at least for the python side of
think) should be enforced by the Openstack foundation/devs as it would
avoid having devs from one project/tool that will join the big tent to use
a different library of its own and so create fragmentation and pitfalls
already mentioned upper on my previous message.

For example, if I let our devs use their own client library for both
GraphQL and workers logic I will end up with at least a dozen of different
libraries per teams and it will be a nightmare to debug, investigate,
maintain etc.

For sure as this is a personal example some could argue that we should
enforce this choice at the company level and not at the solution level, but
if everyone talk the same language its easier to share information, make
consensus around a project, ease the development process by having a clear
and consistent path (Providing a common cookiecutter for all new projects)
and would give us the ability to manage a complete project with the
Openstack client tool such as:

```openstack brick init ```

Here I choose the “brick” term as a keyword in order to avoid namespace
collisions as projects and services are already used for ops side of things.

GraphQL broker:

Ok I see what you means and I honestly love the idea as it’s an elegant way
to split responsibility while being able to scale and efficiently
distribute requests.

I think that’s the implicit idea behind swift-proxy and how (most of)
companies achieve the horizontal scaling with HAProxy as a loadbalancer in
front of classic Openstack WSGI endpoints.

As this is a builtin feature of GraphQL that would allows a way better
service discovery and routing architecture.

Kind regards,
G.

Le mer. 2 mai 2018 à 09:41, Gilles Dubreuil  a écrit :

> I fixed the GraphQL typo (my mistake) in $subject to help with future ML
> searches.
>
> Please see inline too.
>
> On 02/05/18 07:37, Flint WALRUS wrote:
>
> Ok, here are my two cents regarding GraphQL integration within Openstack
> and some thoughts around this topic.
>
> 1°/- Openstack SDK should still exist and should be in my humble opinion a
> critical focus as it allow following benefits for large and medium
> companies :
>
> • It provide a common and clean structure for Openstack developments and
> should be used either by projects or tools willing to integrate Openstack
> as it will then create some sort of standard.
>
> For instance, here in my job we have A LOT (More than 10 000 peoples
> working within around 130 teams) of teams developing over Openstack using
> the SDK as a common shared base layout.
> That allow for teams to easily share and co-develop on projects. Those
> teams are spread around the world and so need to have clean guidelines as
> it avoid them reinventing the wheel, they’re not stuck with someone else
> obscure code created by another persons on the other side of the world or
> within a different timezone.
> Additionally it streamline our support and debug processes.
>
>
> I'm assuming you're talking about the Python SDK (Shade) which would make
> sense because it's the "lingua franca" of all projects.
>
> Nevertheless, for any SDKs/Languages, if adopted then GraphQL is likely to
> replace its REST SDK on the long run. GraphQL is a DSL bypassing a SDK need
> which get replaced with GraphQL client library. Basically the change, not a
> rewrite, is inevitable. But I insist on "the long run" part, initially both
> in parallel one wrapping the other, then progressively the REST content
> moving across to GraphQL.
>
>
> • We should get a common consensus before all projects start to implement
> it.
>
>
>
> This is going to be raised during the API SIG weekly meeting later this
> week.
> API developers (at least one) from every project are strongly welcomed to
> participate.
> I suppose it makes sense for the API SIG to be the place to discuss it, at
> least initially.
>
>
>
> This point is for me the most important one as it will fix flaws we get
> currently with the rest APIs development within Openstack.
>
> First it will avoid a fresh developer to be confused by too many options.
> Honestly, I know we are open etc, but this point really need to be
> addressed as it is the main issue that I face with Openstack advocacy since
> many years now.
>
> Having too many options even if explained within the documentation daunt a
> lot of people to quickly give a hand with projects.
>
> For 

Re: [openstack-dev] Overriding project-templates in Zuul

[Joshua Hesketh]

>
> I think in actuality, both operations would end up as intersections:
>
>     ===  ===
> Matcher   Template  Project  Result
>     ===  ===
> files ABBC   B
> irrelevant-files  ABBC   B
>     ===  ===
>
> So with the "combine" method, it's always possible to further restrict
> where the job runs, but never to expand it.



Ignoring the 'files' above, in the example of 'irrelevant-files' haven't
you just combined the results to expand when it runs? ie, A and C are /not/
excluded and therefore the job will run when there are changes to A or C?

I would expect the table to be something like:
    ===  ===
Matcher   Template  Project  Result
    ===  ===
files ABBC   B
irrelevant-files  ABBC   ABC
    ===  ===



> > So a job with "files: tests/" and "irrelevant-files: docs/" would do
> > whatever it is that happens when you specify both.
>
> In this case, I'm pretty sure that would mean it reduces to just "files:
> tests/", but I've never claimed to understand irrelevant-files and I
> won't start now.
>


Yes, I think you are right that this would reduce to that. However, what
about the use case of:
  files: tests/*
  irrelevant-files: tests/docs/*

I could see a use case where both of those would be helpful. Yes you could
describe that as one regex but to the end user the above may be expected to
work. Unless we make the two options mutually exclusive I feel like this is
a feature we should support. (That said, it's likely a separate
feature/functionality than what is being described now).

Anyway, I feel like Proposal #2 is more how I would expect the system to
behave.

I can see an argument for combining the results (and feel like you could
evaulate that at the end after combining the branch-matching variants) to
give something like:
    ===  ===
Matcher   Template  Project  Result
    ===  ===
files ABBC   ABC
irrelevant-files  ABBC   ABC
    ===  ===

However, that gives the user no way to remove a previously listed option.
Thus overwriting may be the better solution (ie proposal #2 as written)
unless we want to explore the option of allowing a syntax that says
"extend" or "overwrite".

Yours in hoping that made sense,
Josh
__
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] Problems with all OpenStack APIs & uwsgi with Content-Lenght and connection reset by peer (ie: 104)

[Chris Dent]

On Wed, 2 May 2018, Thomas Goirand wrote:


What was disturbing was that, doing the same request with curl worked
perfectly. Even more disturbing, it looked like I was having the issue
nearly always in virtualbox, but not always in real hardware, where it
sometimes worked.


What was making the request in the first place? It fails in X, but
works in curl. What is X?


Anyway, finally, I figured out that adding:

--rem-header Content-Lenght


You added this arg to what?

In both cases do you mean openstackclient?


This however, looks like a workaround rather than a fix, and I wonder if
there's a real issue somewhere that needs to be fixed in a better way,
maybe in openstackclient or some other component...


Yeah, it sounds like something could be setting a bad value for the
content length header and uwsgi is timing out while trying to read
that much data (meaning, it is believing the content-length header)
but there isn't anything actually there.

Another option is that there are buffer size problems in the uwsgi
configuration but it's hard to speculate because it is not clear
what requests and tools you're actually talking about here.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
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] Problems with all OpenStack APIs & uwsgi with Content-Lenght and connection reset by peer (ie: 104)

[Thomas Goirand]

Hi there!

It's been a month I was knocking my head on the wall trying to get uwsgi
working with all of OpenStack API uwsgi applications. Indeed, when
OpenStack component (like for example, nova-compute) were talking to
uwsgi, then they were receiving a 104 error (ie: connection reset by
peer) before getting an answer.

What was disturbing was that, doing the same request with curl worked
perfectly. Even more disturbing, it looked like I was having the issue
nearly always in virtualbox, but not always in real hardware, where it
sometimes worked.

Anyway, finally, I figured out that adding:

--rem-header Content-Lenght

fixed everything. I was able to spawn instances in virtualbox.

This however, looks like a workaround rather than a fix, and I wonder if
there's a real issue somewhere that needs to be fixed in a better way,
maybe in openstackclient or some other component...

Thoughts anyone?

Cheers,

Thomas Goirand (zigo)

__
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] [Zun][k8s] AWS Fargate and OpenStack Zun

[Neil Jerram]

+1 This is beautifully clear and helpful. Thank you!

 Neil


On Wed, 2 May 2018, 02:13 Shuai Zhao,  wrote:

> Thanks Hongbin,
>
> The article is really great!
>
> On Mon, Apr 30, 2018 at 2:40 PM, Kumari, Madhuri  > wrote:
>
>> Thank you Hongbin. The article is very helpful.
>>
>>
>>
>> Regards,
>>
>> Madhuri
>>
>>
>>
>> *From:* Hongbin Lu [mailto:hongbin...@gmail.com]
>> *Sent:* Sunday, April 29, 2018 5:16 AM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Subject:* [openstack-dev] [Zun][k8s] AWS Fargate and OpenStack Zun
>>
>>
>>
>> Hi folks,
>>
>>
>>
>> FYI. I wrote a blog post about a comparison between AWS Fargate and
>> OpenStack Zun. It mainly covers the following:
>>
>>
>>
>> * The basic concepts of OpenStack Zun and AWS Fargate
>>
>> * The Kubernetes integration plan
>>
>>
>>
>> Here is the link:
>> https://www.linkedin.com/pulse/aws-fargate-openstack-zun-comparing-serverless-container-hongbin-lu/
>>
>>
>>
>> Best regards,
>>
>> Hongbin
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Gilles Dubreuil]

I fixed the GraphQL typo (my mistake) in $subject to help with future ML 
searches.


Please see inline too.


On 02/05/18 07:37, Flint WALRUS wrote:
Ok, here are my two cents regarding GraphQL integration within 
Openstack and some thoughts around this topic.


1°/- Openstack SDK should still exist and should be in my humble 
opinion a critical focus as it allow following benefits for large and 
medium companies :


• It provide a common and clean structure for Openstack developments 
and should be used either by projects or tools willing to integrate 
Openstack as it will then create some sort of standard.


For instance, here in my job we have A LOT (More than 10 000 peoples 
working within around 130 teams) of teams developing over Openstack 
using the SDK as a common shared base layout.
That allow for teams to easily share and co-develop on projects. Those 
teams are spread around the world and so need to have clean guidelines 
as it avoid them reinventing the wheel, they’re not stuck with someone 
else obscure code created by another persons on the other side of the 
world or within a different timezone.

Additionally it streamline our support and debug processes.


I'm assuming you're talking about the Python SDK (Shade) which would 
make sense because it's the "lingua franca" of all projects.


Nevertheless, for any SDKs/Languages, if adopted then GraphQL is likely 
to replace its REST SDK on the long run. GraphQL is a DSL bypassing a 
SDK need which get replaced with GraphQL client library. Basically the 
change, not a rewrite, is inevitable. But I insist on "the long run" 
part, initially both in parallel one wrapping the other, then 
progressively the REST content moving across to GraphQL.




• We should get a common consensus before all projects start to 
implement it.



This is going to be raised during the API SIG weekly meeting later this 
week.
API developers (at least one) from every project are strongly welcomed 
to participate.
I suppose it makes sense for the API SIG to be the place to discuss it, 
at least initially.





This point is for me the most important one as it will fix flaws we 
get currently with the rest APIs development within Openstack.


First it will avoid a fresh developer to be confused by too many 
options. Honestly, I know we are open etc, but this point really need 
to be addressed as it is the main issue that I face with Openstack 
advocacy since many years now.


Having too many options even if explained within the documentation 
daunt a lot of people to quickly give a hand with projects.


For instance I have a workmate that is currently working on an 
internal tool which ask me how should he implement its project REST 
interfaces.


I told him TO NOT use WSME and to stick with what have been done by a 
major project. Unfortunately he choose to copy what have been done by 
Octavia which is actually using... WSME...


GraphQL gives us the opportunity and ability to fix Openstack 
development inconsistencies by providing and enforcing a clean 
guideline regarding which library should be used and in which way.


That would also have the side effect to easy the entry level for a new 
Openstack developer.


I couldn't agree more!



• New architecture opportunities.

For sure that will bring new architecture opportunities, but the 
broker thing is not a good idea as each project should be able to be 
autonomous.


I personally don’t like centralized services as it bring SPOF.

Let’s take the AMQP example. For now most of Openstack deployments use 
a RabbitMQ or broker like system.
Even if each (well at least major vanilla projects) services can (and 
should) use ZeroMQ.
I do myself use RabbitMQ but my last weeks were so much 
debugging/investigation hell that we now plan to have a serious 
benchmark and test of ZMQ.


One thing that I would love to see with GraphQL is a better 
distributed and traceable model.




Exactly and the term broker I used is far from ideal,  I meant it in the 
context of a broker pattern providing distributed API service. GraphQL 
has "stiching" capabilities allowing to forward request to diverse 
GraphQL service, kind of a proxy, ideally such service to be distributed 
itself.


The idea behind is a GraphQL proxy offering a single point of entry for 
OpenStack entire stack and of course leaving complete autonomy to the 
all services.


https://blog.graph.cool/graphql-schema-stitching-explained-schema-delegation-4c6caf468405

Anyway, I’m glad someone started this discussion as I feel it is a 
really important topic that would highly help Openstack on more than 
just interfacing topics.
Le mar. 1 mai 2018 à 05:00, Gilles Dubreuil > a écrit :




On 01/05/18 11:31, Flint WALRUS wrote:

Yes, that’s was indeed the sens of my point.


I was just enforcing it, no worries! ;)




Openstack have to provide both endpoints type for a while for
backward compatibility in order to 

[openstack-dev] [neutron] How to specify OpenStack version for Zuul tests?

[Sangho Shin]

Hello,

Is there any way to specify the OpenStack version for Zuul test?

Currently, neteworking-onos project is very outdated, and I need to create a 
stable version for the codes for each OpenStack version (Ocata/Pike/Queens).
Each version of OpenStack has different requirements in particular neutron 
libs, and it seems that Zuul is using the master version of OpenStack for 
testing my codes for Ocata.

Thank you,

Sangho



__
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