Re: [openstack-dev] [tripleo] Nominate Gaël Chamoulaud (gchamoul) for tripleo-validations core
+1 Thanks for the good work! On Fri, Dec 8, 2017 at 8:38 AM, Martin André wrote: > +1! Gaël has been doing a fantastic job in tripleo-validations for a long > time. > > On Thu, Dec 7, 2017 at 3:34 PM, Ana Krivokapic wrote: >> Hey TripleO devs, >> >> Gaël has consistently been contributing high quality reviews and patches to >> the tripleo-validations project. The project would highly benefit from his >> addition to the core reviewer team. >> >> Assuming that there are no objections, we will add Gaël to the core team >> next week. >> >> Thanks! >> >> -- >> Regards, >> Ana Krivokapic >> Senior Software Engineer >> OpenStack team >> Red Hat Inc. >> >> __ >> 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] [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query
Hi Gerg0, I added some comments for GAP-04. It looks like NFVO works as an tenant user and an operator. IMHO, NFVO could calculate the capacity of the cloud. best regards, Masahito On 2017/12/06 22:10, Csatari, Gergely (Nokia - HU/Budapest) wrote: Hi, During the Forum session about the ETSI NFV Gaps I received a request to clarify the scope of the capacity query mentioned in [GAP-04] with ETSI NFV. The advice is that it should be possible to get the capacity of an OpenStack tenant, an user and a resource provider. This is because the NFVO might use different tenants and even different users to manage the resources in the OpenStack instances. Any comments are welcome, also if you need more clarification on the gaps listed in [1] do not hesitate to contact me. Br, Gerg0 [1]: https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained __ 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] Some historic digging
On 12/07/2017 05:23 PM, Steven Hardy wrote:
> On Thu, Dec 7, 2017 at 7:22 AM, Cédric Jeanneret
> wrote:
>> Hello,
>>
>> While trying to add some unit tests for some resources in the
>> puppet-tripleo repository, I stumbled on a not-so-nice case: the
>> tripleo::firewall::service_rules definition.
>>
>> In there, a resource is dynamically taken from hiera, using the
>> following key structure:
>> tripleo..firewall_rules
>>
>> Although this seems to work properly in the tripleo deploy process, it
>> just doesn't work at all for a unit test.
>>
>> After some more digging, it appears the "dot" (".") in YAML is a
>> reserved char for hashes. In the puppet world, we usually use the double
>> semi-colon, aka "::" as a separator.
>>
>> Sooo… I'm wondering what's the history behind that non-puppet-standard
>> choice of "dot" separator, and what would be required in order to move
>> to a more standard syntax for that kind of resources.
>
> dprince may be the best person to answer as IIRC he implemented this
> originally.
>
> However I suspect the choice of "." was deliberate to differentiate
> from :: which implies the hiera values are consumed by puppet class
> interfaces, vs parsed inside the class.
>
Hmm, possible, although.. well, a dedicated prefix might be used in
order to avoid weird things
> Can you work around the yaml issue by using quotes to force the
> "tripleo.foo.firewall" to be a string?
That was the first thing I tried - but nope. YAML seems to want to parse
that and kind of "re-cast" it :(
>
> We don't seem to require that for any templates in
> tripleo-heat-templates though, is that just because the yaml key gets
> cast to a string by hiera?
There might be something in some hiera configuration used in the deploy
process. I'll check the hiera.yaml and try to find something about that
weird string. If we can just report it into the unit tests, it can be
fine. Although... dots... well. ;)
>
>> I've checked the puppet-tripleo repository, and apparently only two
>> resources are using that kind of syntax:
>> - tripleo::firewall::service_rules (already widely present in the
>> tripleo-heat-templates)
>> - tripleo::haproxy::service_endpoints
>> (at least, those are the only resources using a "$underscore_name" variable)
>>
>> Currently, if anyone wants to change something close to those two
>> resources, it won't be tested against regressions, and it's a really bad
>> situation. Especially since it might break central services (closing all
>> firewall ports isn't good, for example, or dropping an haproxy endpoint
>> by mistake)… Unit tests are needed, especially in such a huge piece of
>> software ;).
>
> Yeah I think we need to know more about the reasons this syntax won't
> work for unit tests, we could conceivably change it, but as you say
> it's widely used for firewall rules, and could potentially break any
> out of tree service templates that exist, so we'd have to follow a
> deprecation process to change the interface.
Hmmm ok. I didn't check outside of the puppet-tripleo - it indeed might
be some things using this string format. I've already pushed two reviews
that *adds* support for the "::" notation for the said resources. That
way, we have at least a basis for a smooth move. Of course, they are
only "reviews", so they have to be accepted:
https://review.openstack.org/#/c/526589/
https://review.openstack.org/#/c/526292/
I doubt out-of-tree stuff uses those hiera entries, but of course this
would require some grep and, probably, advice from other contributors ;).
Thank you for your feedback!
>
> Thanks,
>
> Steve
>
> __
> 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
>
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] [tripleo] Nominate Gaël Chamoulaud (gchamoul) for tripleo-validations core
On Thu, Dec 7, 2017 at 4:34 PM, Ana Krivokapic wrote: > Hey TripleO devs, > > Gaël has consistently been contributing high quality reviews and patches > to the tripleo-validations project. The project would highly benefit from > his addition to the core reviewer team. > > Assuming that there are no objections, we will add Gaël to the core team > next week. > +1 > > Thanks! > > -- > Regards, > Ana Krivokapic > Senior Software Engineer > OpenStack team > Red Hat Inc. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] multiple federated keystones with single Identity Provider
Hi Pavlo, I think that there are viable alternatives to your specific use case having single external idp for federated auth. Depending on your IT environment architecture and preferences you have the following possibilities, both of them are providing very smooth user experience: - in AD centric environments connect each of Keystone services to AD and leverage Kerberos for SSO. You can consume REMOTE_USER and other variables from AD directly via mod_auth_gssapi and mod_lookup_identity. Advantage of this approach is that you can leverage AD native SSO mechanism based on SPNEGO. So you are not any longer forcing users to perform SAML or OIDC referrals etc. - in both AD or non AD centric environments you can leverage 'Tokenless Auth' plugin, which basically can also be used with Keystone to issue tokens (e.g. Fernet) and perform token scoping based on X.509 certificate properties. You can also configure specific X.509 certificate attributes e.g. SAN or subjectDirectoryAttributes to control access for specific region or Keystone instance. On Fri, Dec 8, 2017 at 1:25 AM, Boris Bobrov wrote: > Hi, > > > On 12/07/2017 12:27 PM, Colleen Murphy wrote: > >> On Thu, Dec 7, 2017 at 5:37 PM, Pavlo Shchelokovskyy > >> wrote: > >>> Hi all, > >>> > >>> We have a following use case - several independent keystones (say KeyA > and > >>> KeyB), using fernet tokens and synchronized fernet keys, and single > external > >>> IdP for federated auth. > >>> > >>> Is it generally possible to configure both KeyA and KeyB such that > scoped > >>> token issued by KeyA for a federated user is valid on KeyB? > >>> > >>> Currently we have the next problem - although domains/projects where > >>> keystone's mapping engine assigns federated users are equal by name > between > >>> KeyA and KeyB, the UUIDs of projects/domains in KeyA and KeyB are > >>> different, which seems to invalidate the scoped token issued by KeyA > when > >>> trying to use it for KeyB. And it is not possible to create > projects/domains > >>> with specific UUIDs via keystone API (which would probably solve this > >>> problem for non-autoprovisioned projects). > >>> > >>> Is such usage scenario supported? Or one should always use the unscoped > >>> token first to list projects/domains available on a specific keystone > >>> instance and then get a scoped token for usage o this instance only? > >> No, it is not currently possible to use the same token on projects in > >> different keystones, for the reasons you gave. You might be interested > >> in following https://review.openstack.org/#/c/323499/ if you're not > >> already aware of it, which has the goal of solving that problem. > >> > >> It's also been brought up before: > >> > >> https://review.openstack.org/#/c/403866/ > >> http://lists.openstack.org/pipermail/openstack-dev/2016- > December/108466.html > >> > >> And we talked about it a lot at the last Forum (sorry my brief summary > >> does not really do the discussion justice): > >> > >> http://www.gazlene.net/sydney-summit.html#keystone-operator- > and-user-feedback > > I had a snippet about it in my recap under the "Other Feedback" section > > [0]. The TL;DR in my opinion is that we originally thought we could > > solve the problem with federation 100%, and if we couldn't we wanted to > > try and improve the parts of federation that would make that possible. > > > > The interesting bit we came up with during the feedback session in > > Sydney is what happens if a user no longer has a role on a project. For > > example; > > > > - A user has a role on Project A and in the us-east region and the > > us-west region, each region has it's own keystone deployment, but let's > > assume the ID for Project A are the same in each region > > - A user authenticates for a token scoped to Project A and starts > > creating instances in both regions > > - The user has their role from Project A removed in us-east, but not in > > us-west > > - The user isn't able to do anything within us-east since they no longer > > have a role assignment on Project A in that region, but they can still > > take the invalid token from the us-east region and effectively use it in > > the us-west region > > > > Without replicating revocation events, or syncing the assignment table, > > this will lead to security concerns. > > There is also cache invalidation issue. And that would make tokens of > various scope behave in a different manner. A year ago i was -2 on this, > and i still don't think this is a good idea. > > If there is a demand to control several clouds from single place, > K2K support should be added where it is needed. > > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. _
[openstack-dev] [tripleo] [upgrade] CI status and Current effort.
Hi, We (Upgrade Squad) have eventually save some time for fixing/creating the needed upgrade/update jobs. We have made an inventory of what currently exists there[1] and what is missing in the same spreadsheet. I recap the missing one here: - minor updates (master and pike) - UC non containerized to containerized - ffu-undercould-upgrade - ffu-overcloud-upgrade We are currently working on fixing the existing ocata->pike upgrade. You don’t see pike->master as we are reworking the workflow (as usual) and it’s non working. But we have a jobs to track the progress in experimental[2] with the right depends-on. The two newcomers are FFU uc upgrade and oc upgrade (Fast Forward Upgrade, or upgrade from Newton to Queens). We have a work in progress there[3] and there[4] for oc upgrade. It’s not yet working but would be nice to have those jobs in experimental as soon as we can to track our progress there and detect code/repo deletion that prevents the whole FFU to function. We’re are working on minor upgrade testing there[5] and there[6] Oki, nearly done... We have the tripleo-upgrade role that is stuck in transition. This repo is an effort to share downstream QE testing with upstream. Du to various reasons (speed, mainly) we kept using github instead of switching to the openstack one. Now we are stuck there[7]. We would like a new import but if it is not possible, we will merge all the patches manually. So currently we don’t use the role but when it will be there we will do the switch. Thanks, -- [1] https://ethercalc.openstack.org/iv2jr35o98 [2] https://review.openstack.org/#/c/526006/ [3] https://review.openstack.org/#/q/topic:ffu/ci+(status:open+OR+status:merged) [4] https://review.rdoproject.org/r/10827 [5] https://review.openstack.org/#/q/topic:upgrade/ci+(status:open+OR+status:merged) [6] https://review.rdoproject.org/r/#/c/10878/ [7] https://review.openstack.org/#/c/524141/ -- Sofer __ 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] [upgrade] CI status and Current effort.
On Fri, Dec 8, 2017 at 4:32 AM, Sofer Athlan-Guyot wrote: > Hi, > > We (Upgrade Squad) have eventually save some time for fixing/creating > the needed upgrade/update jobs. > > We have made an inventory of what currently exists there[1] and what is > missing in the same spreadsheet. > > I recap the missing one here: > > - minor updates (master and pike) > - UC non containerized to containerized > - ffu-undercould-upgrade > - ffu-overcloud-upgrade > > We are currently working on fixing the existing ocata->pike upgrade. > > You don’t see pike->master as we are reworking the workflow (as usual) > and it’s non working. But we have a jobs to track the progress in > experimental[2] with the right depends-on. > > The two newcomers are FFU uc upgrade and oc upgrade (Fast Forward > Upgrade, or upgrade from Newton to Queens). We have a work in progress > there[3] and there[4] for oc upgrade. > > It’s not yet working but would be nice to have those jobs in > experimental as soon as we can to track our progress there and detect > code/repo deletion that prevents the whole FFU to function. > > We’re are working on minor upgrade testing there[5] and there[6] > > Oki, nearly done... > > We have the tripleo-upgrade role that is stuck in transition. This repo > is an effort to share downstream QE testing with upstream. Du to > various reasons (speed, mainly) we kept using github instead of > switching to the openstack one. Now we are stuck there[7]. We would > like a new import but if it is not possible, we will merge all the > patches manually. > > So currently we don’t use the role but when it will be there we will do > the switch. > > Thanks, > -- > [1] https://ethercalc.openstack.org/iv2jr35o98 > [2] https://review.openstack.org/#/c/526006/ > [3] https://review.openstack.org/#/q/topic:ffu/ci+(status:open+ > OR+status:merged) > [4] https://review.rdoproject.org/r/10827 > [5] https://review.openstack.org/#/q/topic:upgrade/ci+(status: > open+OR+status:merged) > [6] https://review.rdoproject.org/r/#/c/10878/ > [7] https://review.openstack.org/#/c/524141/ > -- > Sofer > Sofer, can you estimate when the redhat-openstack gerrit repo will be dropped and the upstream openstac/tripleo-upgrades role used in it's place. I need to coordinate the CI team to work you and Jose Louis, however not using the upstream repo makes that difficult. We have a meeting today, so we can also talk about it there. Thanks > > __ > 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] [nova] [placement] resource providers update 44
I'm feeling pressure from the (excellent and welcomed) Weekly Owl http://lists.openstack.org/pipermail/openstack-dev/2017-December/125214.html and Keystone update: http://lists.openstack.org/pipermail/openstack-dev/2017-December/125112.html to enhance the rp and placement update brand, to maximize market penetration, global influence, and reader participation, but instead I'll stick to habit. # Most Important The three main themes (nested providers, alternate hosts, migration) continue to be the main priorities. A thing to be aware of, now that some of nested has merged on the placement side, is that the nova side is underway and the work surrounding the ProviderTree concept is fairly penetrating. It will supersede the "get_inventory" method in the virt drivers, and thus far not all the virt drivers have get_inventory methods. See https://review.openstack.org/#/c/521187/ way down inside the nested-resource-providers topic for a bit of context. # What's Changed Microversion 1.14 has merged (causing a might microversion conflict pileup behind it) meaning that some aspects of nested providers are in the placement API. Hierarchies of providers can be created, and trees of results can be returned: https://developer.openstack.org/api-ref/placement/#create-resource-provider https://developer.openstack.org/api-ref/placement/#list-resource-providers A fix was merged that defaults the accept header, if not set, to application/json. This means that whereas in the past an error response could inadvertently be HTML, it will now be JSON, structured (partially, critically the 'code' field is not there as we've stumbled trying to create standards) according to the errors guideline: https://review.openstack.org/#/c/518223/ http://specs.openstack.org/openstack/api-wg/guidelines/errors.html Eric made the compute node be more alert when it encounters an error condition when getting or creating resource providers: https://review.openstack.org/#/c/524263/ This led to the discovery that in grenade placement was not being properly stopped and restarted over the upgrade transition: https://review.openstack.org/#/c/525605/ I mention all this because it's quite likely that latent bugs with talking to placement (from nova) in grenade will be exposed. Be on the lookout. If you find something weird, report a bug, and if possible, fix it. # Help Wanted (unchanged from last week, no new data, yet) A takeaway from summit is that we need, where possible, benchmarking info from people who are making the transition from old methods of scheduling to the newer allocation_candidate driven modes. While detailed numbers will be most useful, even anecdotal summaries of "woot it's way better" or "hmmm, no it seems worse" are useful. # Docs Quite a few docs improvements have merged. Others need more review: * https://review.openstack.org/#/c/512215/ Add create inventories doc for placement * https://review.openstack.org/#/c/523007/ Add x-openstack-request-id in API ref * https://review.openstack.org/#/c/521541/ Add 'Location' parameters in API ref * https://review.openstack.org/#/c/511342/ add API reference for create inventory # Nested Providers The nested-resource-providers stack has grown a long tail of changes for managing nested providers rooted on a compute node: https://review.openstack.org/#/q/topic:bp/nested-resource-providers As mentioned above this has impact for virt drivers. The current spec for nested providers http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/nested-resource-providers.html doesn't really cover the ProviderTree and inventory management plans that are currently being implemented in that long tail. That makes it a bit harder to review than it might otherwise. We may not need a spec but a sort of explanatory overview may help provide some context on what needs to happen. A lot of the work that is in progress feels like it is working to a design where the use cases are not entirely obvious. There's a danger this can lead to an implementation that is somewhat divorced for reality. There's no evidence as yet that this is happening, but there's also none that it's not. ## Alternate Hosts Having the scheduler request and use alternate hosts: https://review.openstack.org/#/q/topic:bp/return-alternate-hosts This has come unstuck and is moving along, but needs continued eyes. ## Migration allocations Do allocation "doubling" using the migration uuid for the consumer for one half. This is also very close: https://review.openstack.org/#/c/507638/ The concept of migration allocations is what drove the work to enable the POST /allocations handling now at microversion 1.13, so we have the option to start using that power. Dan helpfully left comments in the code to indicate where it could be done. Do we want to consider getting that in before the end of queens, to avoid some racing? ## Misc Traits, Shar
Re: [openstack-dev] [neutron][l2gw] Preventing DB out-of-sync
On Wed, Dec 6, 2017 at 3:46 AM, Peng Liu wrote: > Hi, > > During working on this patch[0], I encounter some DB out-of-sync problem. I > think maybe the design can be improved. Here is my thought, all comments are > welcome. see also https://review.openstack.org/#/c/490834/ which I think is dealing with a similar (if not the same) issue. > > In plugin code, I found all the resource operations follow the pattern in > [1]. It is a very misleading design compare to [2]. > > "For every action that can be taken on a resource, the mechanism driver > exposes two methods - ACTION_RESOURCE_precommit, which is called within the > database transaction context, and ACTION_RESOURCE_postcommit, called after > the database transaction is complete." > > In result, if we focus on the out-of-sync between plugin DB and > driver/backend DB: > > 1) In RPC driver, only methods Action_Resource and are implemented. Which > means the action is token before it was written in plugin DB. In case of > action partial succeed (especially for update case) or plugin DB operation > failure, it will cause DB out-of-sync. > 2) In ODL driver, only methods Action_Resource_postcommit are implemented, > which means there is no validation in ODL level before the record is written > in the plugin DB. In case of, ODL side failure, there is no rollback for > plugin DB. > > So, to fix this issue is costly. Both plugin and driver sides need to be > altered. > > The other side of this issue is a period db monitor mechanism between plugin > and drivers, and it is another story. > > > [0] https://review.openstack.org/#/c/516256 > [1] > ... > def Action_Resource > self.validate_Resource_for_Action > self.driver.Action_Resource > with context.session.begin(subtransactions=True): > super.Action_Resource > self.driver.Action_Resource_precommit > try: > self.driver.Action_Resource_postcommit > ... > [2] https://wiki.openstack.org/wiki/Neutron/ML2 > > -- > Peng Liu > > __ > 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] [Zun] PTL on vacation for 3 weeks
Hi team, I will be on vacation during Dec 11 - Jan 2. Madhuri Kumari (cc-ed) kindly agreed to serve the PTL role while I am away. Wish everyone have a happy holiday. 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-dev] [tripleo][ffu] Fast-forward upgrades M2 progress report
Hello all, This is a brief progress report from the Upgrades squad for the fast-forward upgrades (FFU) feature in TripleO, introducing N to Q upgrades. tl;dr Good initial progress, missed M2 goal of nv CI jobs, pushing on to M3. Overview For anyone unfamiliar with the concept of fast-forward upgrades the following sentence from the spec gives a brief high level introduction: > Fast-forward upgrades are upgrades that move an environment from release `N` > to `N+X` in a single step, where `X` is greater than `1` and for fast-forward > upgrades is typically `3`. The spec itself obviously goes into more detail and I'd recommend anyone wanting to know more about our approach for FFU in TripleO to start there: https://specs.openstack.org/openstack/tripleo-specs/specs/queens/fast-forward-upgrades.html Note that the spec is being updated at present by the following change, introducing more details on the FFU task layout, ordering, dependency on the on-going major upgrade rework in Q, canary compute validation etc: WIP ffu: Spec update for M2 https://review.openstack.org/#/c/526353/ M2 Status - The original goal for Queens M2 was to have one or more non-voting FFU jobs deployed *somewhere* able to run through the basic undercloud and overcloud upgrade workflows, exercising as many compute service dependencies as we could up to and including Nova. Unfortunately while Sofer has made some great progress with this we do not have any running FFU jobs at present: http://lists.openstack.org/pipermail/openstack-dev/2017-December/125316.html We do however have documented demos that cover FFU for some limited overcloud environments from Newton to Queens: OpenStack TripleO FFU Keystone Demo N to Q https://blog.yarwood.me.uk/2017/11/16/openstack_fastforward_tripleo_keystone/ OpenStack TripleO FFU Nova Demo N to Q https://blog.yarwood.me.uk/2017/12/01/openstack_fastforward_tripleo_nova/ These demos currently use a stack of changes against THT with the first ~4 or so changes introducing the FFU framework: https://review.openstack.org/#/q/status:open+project:openstack/tripleo-heat-templates+branch:master+topic:bp/fast-forward-upgrades FWIW getting these initial changes merged would help avoid the current change storm every time this series is rebased to pick up upgrade or deploy related bug fixes. Also note that the demos currently use the raw Ansible playbooks stack outputs to run through the FFU tasks, upgrade tasks and deploy tasks. This is by no means what the final UX will be, with python-tripleoclient and workflow work to be completed ahead of M3. M3 Goals The squad will be focusing on the following goals for M3: - Non-voting RDO CI jobs defined and running - FFU THT changes tested by the above jobs and merged - python-tripleoclient & required Mistral workflows merged - Use of ceph-ansible for Ceph upgrades - Draft developer and user docs under review FFU squad - Finally, a quick note to highlight that this report marks the end of my own personal involvement with the FFU feature in TripleO. I'm not going far, returning to work on Nova and happy to make time to talk about and review FFU related changes etc. The members of the upgrade squad taking this forward and your main points of contact for FFU in TripleO will be: - Sofer (chem) - Lukas (social) - Marios (marios) My thanks again to Sofer, Lukas, Marios, the rest of the upgrade squad and wider TripleO community for your guidance and patience when putting up with my constant inane questioning regarding FFU over the past few months! Cheers, Lee -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 signature.asc Description: PGP 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
[openstack-dev] [Neutron] Shifting the bug deputy schedule
Dear Neutrinos, Recently two members of the team have been re-assigned by their companies to other duties. As a consequence, we need to adjust our bugs deputy schedule and your duty slot will be one week sooner than originally expected. Please take some time to check the revised schedule here: https://wiki.openstack.org/wiki/Network/Meetings Best regards Miguel __ 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 Ops Meetup Topic Brainstorming
https://etherpad.openstack.org/p/TYO-ops-meetup-2018 Hey everyone, Just a friendly reminder that the Ops Meetup for Spring 2018 is approaching March 7-8, 2018 in Tokyo and we are looking for topics. Some have been gathered already but brainstorming could definitely use some love. What is different about this meetup compared to others is the addition of focus areas; tracks. Spring 2018 will have NFV+General on day one and Enterprise+General on day two. Add additional topics to the etherpad or +/- 1 those already proposed. -- Kind regards, Melvin Hillsman mrhills...@gmail.com mobile: (832) 264-2646 __ 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 Team Update - Week of 4 December 2017
# Keystone Team Update - Week of 4 December 2017 ## News ### Keystone Queens-2 Retrospective We used our meeting time for our milestone-ly team retrospective, which took place on Google Hangouts. We were unfortunately not able to record the session but the Trello board reflects the discussion topics[1]. One of the key topics that came up was the potential of moving our roadmap management from Trello to Storyboard. Earlier advice from the Storyboard folks advised that there would be a mass migration for all interlinked projects, but the current evolution of the plan promotes a more iterative approach. See the discussion on the Community Goal governance review[2]. The major hindrance to keystone using Storyboard is its lack of support for private bugs, which is a requirement given that keystone is a VMT-managed project. If anyone is tired of keystone work and wants to help the Storyboard team with that feature I'm sure they would appreciate it! In any case, we don't want to switch our roadmap tooling in the middle of a cycle, so we would continue to use Trello for roadmap tracking until a cycle change. [1] https://trello.com/b/jrpmDKtf/keystone-retrospective [2] https://review.openstack.org/#/c/513875/4/goals/rocky/storyboard_migration.rst@82 ### Policy Meetings The last policy meeting was pretty quiet[3]. We decided to cancel policy meetings until after the holidays. [3] http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-12-06-16.00.log.txt ### Longer project names We rejected Adrian's patch to extend the maximum length of project names from 64 to 255 characters[4]. While it might initially seem like a harmless expansion, it is actually an API breakage because it changes a response from a 400 to a 200. Keystone does not currently implement microversions, but we think that microversions would still not be helpful here, for reasons I described on that patch. We'd like to look for an alternative way to support Adrian's use case[5]. [4] https://review.openstack.org/#/c/440941/ [5] http://lists.openstack.org/pipermail/openstack-dev/2016-October/106288.html ## Open Specs Search query: https://goo.gl/pc8cCf We are closing in on the Limits API spec[6]. We had a good discussion about it today[7] where we walked through some of the API compatibility implications of whether or not to start defining and implementing hierarchical quota models at this stage and reached a satisfactory conclusion. We'll likely make a spec freeze exception for this spec so that we can flesh this out fully and get feedback from other teams. We also have renewed interest in a feature allowing control over the generation of project IDs[8], a request that has been independently made by multiple groups over the years but has historically been resisted by the keystone team. [6] https://review.openstack.org/#/c/455709/ [7] http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2017-12-08.log.html#t2017-12-08T15:00:28 [8] https://review.openstack.org/#/c/323499/ ## Recently Merged Changes Search query: https://goo.gl/hdD9Kw We merged 17 changes this week. Among those are a couple of patches that push us further down our policy roadmap: Enforce policy on oslo-context: https://review.openstack.org/#/c/523650/ Add scope_types to RuleDefault objects: https://review.openstack.org/#/c/510222/ We also finally moved keystonemiddleware to using oslo.cache instead of using the python-memcached library directly: Use oslo_cache in auth_token middleware: https://review.openstack.org/#/c/268664/ ## Changes that need Attention Search query:https://goo.gl/YiLt6o There are 49 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots, so their authors are waiting for feedback from reviewers. Please have a look at them. In particular, Adam has been working on finishing the is_admin_project work: https://goo.gl/dDojbk Lance is closing in on the system-scope implementation: https://goo.gl/2nLbVx ## Milestone Outlook https://releases.openstack.org/queens/schedule.html Queens-2 is today. Lance has been preparing releases for this milestone: https://goo.gl/GQBeAi Spec freeze is today but we'll likely make an exception for the Limits API spec. Our next deadline is for the Feature Proposal Freeze at Rocky-10. ## Shout-outs Thanks Harry Rybacki for leading our retrospective! ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Keystone Team Update - Week of 4 December 2017
On 2017-12-08 18:48:56 +0100 (+0100), Colleen Murphy wrote: [...] > The major hindrance to keystone using Storyboard is its lack of > support for private bugs, which is a requirement given that > keystone is a VMT-managed project. If anyone is tired of keystone > work and wants to help the Storyboard team with that feature I'm > sure they would appreciate it! [...] I also followed up on this topic in the SB meeting yesterday[*] and realized support is much further along than I previously recalled. In summary, SB admins can define "teams" (e.g., OpenStack VMT) and anyone creating a private story can choose to share it with any teams or individual accounts they like. What we're mostly missing at this point is a streamlined reporting mechanism to reduce the steps (and chances to make mistakes) when reporting a suspected vulnerability. A leading candidate solution would be support for custom reporting URLs which can feed arbitrary values into the creation form. [*] http://eavesdrop.openstack.org/meetings/storyboard/2017/storyboard.2017-12-06-19.05.log.html#l-36 -- Jeremy Stanley signature.asc Description: 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] [tripleo] Nominate Gaël Chamoulaud (gchamoul) for tripleo-validations core
+1 On Thu, Dec 7, 2017 at 7:34 AM, Ana Krivokapic wrote: > Hey TripleO devs, > > Gaël has consistently been contributing high quality reviews and patches to > the tripleo-validations project. The project would highly benefit from his > addition to the core reviewer team. > > Assuming that there are no objections, we will add Gaël to the core team > next week. > > Thanks! > > -- > Regards, > Ana Krivokapic > Senior Software Engineer > OpenStack team > Red Hat Inc. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Keystone Team Update - Week of 4 December 2017
On Fri, Dec 08, 2017 at 05:58:05PM +, Jeremy Stanley wrote: > On 2017-12-08 18:48:56 +0100 (+0100), Colleen Murphy wrote: > [...] > > The major hindrance to keystone using Storyboard is its lack of > > support for private bugs, which is a requirement given that > > keystone is a VMT-managed project. If anyone is tired of keystone > > work and wants to help the Storyboard team with that feature I'm > > sure they would appreciate it! > [...] > > I also followed up on this topic in the SB meeting yesterday[*] and > realized support is much further along than I previously recalled. > In summary, SB admins can define "teams" (e.g., OpenStack VMT) and > anyone creating a private story can choose to share it with any > teams or individual accounts they like. What we're mostly missing at > this point is a streamlined reporting mechanism to reduce the steps > (and chances to make mistakes) when reporting a suspected > vulnerability. A leading candidate solution would be support for > custom reporting URLs which can feed arbitrary values into the > creation form. > > [*] > http://eavesdrop.openstack.org/meetings/storyboard/2017/storyboard.2017-12-06-19.05.log.html#l-36 > Thanks to both for pointing this out again. I too didn't know it was possible to create teams for private stories. Sounds like we are slowly making progress on this blocker for some of our projects. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Keystone Team Update - Week of 4 December 2017
On Fri, Dec 8, 2017 at 6:58 PM, Jeremy Stanley wrote: > On 2017-12-08 18:48:56 +0100 (+0100), Colleen Murphy wrote: > [...] >> The major hindrance to keystone using Storyboard is its lack of >> support for private bugs, which is a requirement given that >> keystone is a VMT-managed project. If anyone is tired of keystone >> work and wants to help the Storyboard team with that feature I'm >> sure they would appreciate it! > [...] > > I also followed up on this topic in the SB meeting yesterday[*] and > realized support is much further along than I previously recalled. > In summary, SB admins can define "teams" (e.g., OpenStack VMT) and > anyone creating a private story can choose to share it with any > teams or individual accounts they like. What we're mostly missing at > this point is a streamlined reporting mechanism to reduce the steps > (and chances to make mistakes) when reporting a suspected > vulnerability. A leading candidate solution would be support for > custom reporting URLs which can feed arbitrary values into the > creation form. > > [*] > http://eavesdrop.openstack.org/meetings/storyboard/2017/storyboard.2017-12-06-19.05.log.html#l-36 > > -- > Jeremy Stanley > Thanks for pointing this out! Good to know this is moving along. Colleen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Keystone Team Update - Week of 4 December 2017
On 2017-12-08 19:21:39 +0100 (+0100), Colleen Murphy wrote: [...] > Thanks for pointing this out! Good to know this is moving along. Well, I wouldn't want to give the impression that it's all squared away... as your original message indicated, the SB team would _definitely_ love assistance from others in the community on getting solutions for these sorts of migration blockers implemented; so please anyone interested in helping pop into #storyboard and there are usually people around even if it seems relatively quiet. ;) -- Jeremy Stanley signature.asc Description: 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] [tripleo][ffu] Fast-forward upgrades M2 progress report
On Fri, Dec 8, 2017 at 8:51 AM, Lee Yarwood wrote: [...] > My thanks again to Sofer, Lukas, Marios, the rest of the upgrade squad > and wider TripleO community for your guidance and patience when putting > up with my constant inane questioning regarding FFU over the past few > months! Thanks Lee for your hard work on this topic, your patience with TripleO community and all your transparency via the mailing-list and blog posts. It was really helpful! -- 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
[openstack-dev] [keystone] specification freeze exception for unified limits
Hey all, We had a really productive conversation [0] regarding the outstanding concerns with the unified limits proposal. The initial implementation for unified limits should target a model so that we can do proper limit validation. The specification has been reworked to include the outcomes of the conversation. I'm proposing we issue a specification freeze exception for the unified limits specification [1]. We've made a ton of good progress on it and wxy has been diligently updating the spec and implementation. If you have any concerns with the new direction or the discussion we had today, please let me know. If everyone is OK with the direction and the exception, we'll plan to have the specification smoothed out and merged by the end of next week. Thanks, Lance [0] http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2017-12-08.log.html#t2017-12-08T15:00:28 [1] https://review.openstack.org/#/q/status:open+project:openstack/keystone-specs+branch:master+topic:bp/unified-limits 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] [tripleo] [upgrade] CI status and Current effort.
On Fri, Dec 8, 2017 at 5:39 AM, Wesley Hayutin wrote: [...] > Sofer, can you estimate when the redhat-openstack gerrit repo will be > dropped and the upstream > openstac/tripleo-upgrades role used in it's place. I need to coordinate the > CI team to work you and > Jose Louis, however not using the upstream repo makes that difficult. When https://review.openstack.org/#/c/524141/ will be merged - we're working on that. Alex cleanup the repo, today I rebased the patch and added ansble-lint tests. When we have lint working, we'll probably merge the patch. From then, I don't see any blocker to use the upstream repo. -- 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] [tripleo] [upgrade] CI status and Current effort.
On Fri, Dec 8, 2017 at 1:32 AM, Sofer Athlan-Guyot wrote: [...] > So currently we don’t use the role but when it will be there we will do > the switch. > > Thanks, Thanks a ton Sofer for all these upgrades. It's excellent to see these kinds of updates more frequently on the mailing-list it really helps. Also, it's really cool to see the Upgrade Squad catching up more quickly on the cycles than before. At least but not last, it's awesome to see all these efforts in upstream CI, we really need it. Please let us know if we can help more (reviews, testing, etc). Thanks again, -- 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] [Tripleo] Some historic digging
On 08/12/17 03:51, Cédric Jeanneret wrote:
On 12/07/2017 05:23 PM, Steven Hardy wrote:
On Thu, Dec 7, 2017 at 7:22 AM, Cédric Jeanneret
wrote:
After some more digging, it appears the "dot" (".") in YAML is a
reserved char for hashes. In the puppet world, we usually use the double
semi-colon, aka "::" as a separator.
Can you work around the yaml issue by using quotes to force the
"tripleo.foo.firewall" to be a string?
That was the first thing I tried - but nope. YAML seems to want to parse
that and kind of "re-cast" it :(
There is most definitely no such thing in YAML:
>>> yaml.safe_load('- tripleo.foo.firewallrules:\nbar: baz')
[{'tripleo.foo.firewallrules': {'bar': 'baz'}}]
The problem is hiera:
https://puppet.com/docs/puppet/5.1/hiera_subkey.html
Discussion:
https://tickets.puppetlabs.com/browse/HI-496
The quoting thing was added comparatively recently (March 2016), so
maybe that's why it isn't working for you:
https://tickets.puppetlabs.com/browse/HI-504
- 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
[openstack-dev] Gerrit custom menu entries - help needed
Hello, I’m trying to personalize my Gerrit menus in settings panel on review.openstack.org. So I prepared query like: (NOT owner:self) AND status:open AND label:Code-Review-0,self AND label:Workflow=0 AND (project:openstack/neutron OR project:openstack/neutron-lib) AND branch:master And I wanted to create menu entry with this query. When I’m pasting query: #/q/(NOT+owner:self)+AND+status:open+AND+label:Code-Review-0%252Cself+AND+label:Workflow%253D0+AND+(project:openstack/neutron+OR+project:openstack/neutron-lib)+AND+branch:master On gerrit settings page it replaces me chars like , or = to something else and query looks like: #/q/(NOT+owner:self)+AND+status:open+AND+label:Code-Review-0%252Cself+AND+label:Workflow%253D0+AND+(project:openstack/neutron+OR+project:openstack/neutron-lib)+AND+branch:master And it don’t work properly then. So I have a question to more experienced Gerrit users. What I’m doing wrong here and how I should create menu entry with query which I really want? — Best regards Slawek Kaplonski sla...@kaplonski.pl signature.asc Description: Message signed with OpenPGP __ 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] [Release-job-failures][congress] Pre-release of openstack/congress failed
Excerpts from zuul's message of 2017-12-08 21:56:33 +: > Build failed. > > - release-openstack-python-without-pypi > http://logs.openstack.org/08/080df7f0b147dc8290cc9ceb513ba5d8c1f8f295/pre-release/release-openstack-python-without-pypi/8c423e5/ > : FAILURE in 5m 53s > - announce-release announce-release : SKIPPED > This error looks like there is a bad file reference in the MANIFEST.in: error: can't copy 'etc/policy.json': doesn't exist or not a regular file ERROR: InvocationError: '/home/zuul/src/git.openstack.org/openstack/congress/.tox/venv/bin/python setup.py bdist_wheel' venv finish: runtests after 2.76 seconds __ 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] [Release-job-failures][congress] Pre-release of openstack/congress failed
On Fri, Dec 08, 2017 at 04:06:15PM -0600, Doug Hellmann wrote: > Excerpts from zuul's message of 2017-12-08 21:56:33 +: > > Build failed. > > > > - release-openstack-python-without-pypi > > http://logs.openstack.org/08/080df7f0b147dc8290cc9ceb513ba5d8c1f8f295/pre-release/release-openstack-python-without-pypi/8c423e5/ > > : FAILURE in 5m 53s > > - announce-release announce-release : SKIPPED > > > > This error looks like there is a bad file reference in the MANIFEST.in: > > error: can't copy 'etc/policy.json': doesn't exist or not a regular file > ERROR: InvocationError: > '/home/zuul/src/git.openstack.org/openstack/congress/.tox/venv/bin/python > setup.py bdist_wheel' > venv finish: runtests after 2.76 seconds I think this is needed to fix it. Some missing cleanup work from the policy-in-code activity. https://review.openstack.org/#/c/526274/ __ 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] Technical Committee Status update, December 8th
Hi! This is the weekly summary of Technical Committee initiatives. You can find the full list of all open topics (updated twice a week) at: https://wiki.openstack.org/wiki/Technical_Committee_Tracker If you are working on something (or plan to work on something) that is not on the tracker, feel free to add to it ! == Recently-approved changes == * Officialize election organization working group [1] * stop linking to documentation from governance [2] * Tags are applied to deliverables, or teams [3] * Remove redundant links in index.rst [4] * Update URL for TC tracker on the wiki [5] * New repos: masakari-dashboard, log-classify, ansible-role-k8s-glance * Goal updates: vitrage, panko [1] https://review.openstack.org/521062 [2] https://review.openstack.org/523195 [3] https://review.openstack.org/#/c/523886/ [4] https://review.openstack.org/523121 [5] https://review.openstack.org/523381 Nothing really significant this week, mostly a bunch of cleanup changes and clarifications. == Voting in progress == Monty's patch updating shade team metainfo is still missing a couple of votes: https://review.openstack.org/523519 Doug Hellmann proposes to round up our top-5 "help needed" list with goal champions. His proposal is still short of a couple of votes: https://review.openstack.org/510656 The patch to remove the unused docs:follows-policy tag reached majority and will be approved on Tuesday unless new objections are posted: https://review.openstack.org/524217 == Under discussion == Graham Hayes proposed various options to clarify how the testing of interoperability programs should be organized, in the age of add-on trademark programs. It is a difficult trade-off between the benefits of centralizing reviews and decentralizing reviews for that specific area. Please chime in on the review: https://review.openstack.org/521602 Matt Treinish proposed an update to the Python PTI for tests to be specific and explicit. Wider community input is needed on that topic. Please review at: https://review.openstack.org/519751 The "top-5 help wanted list" assumes there will always be 5 items, and the name is a bit of a mouthful. Naming is hard. Current proposal is to call is the "help most needed" list. If you prefer your bikesheds painted in blue, please comment at: https://review.openstack.org/520619 Emilien Macchi officially launched the goal proposing season for the Rocky cycle in a thread at: http://lists.openstack.org/pipermail/openstack-dev/2017-November/124976.html We already have one proposal on the docket (Storyboard migration), thanks to Kendall Nelson. Please chime in on whether it's a good idea at: https://review.openstack.org/513875 == TC member actions for the coming week(s) == Nothing specific. == Office hours == To be more inclusive of all timezones and more mindful of people for which English is not the primary language, the Technical Committee dropped its dependency on weekly meetings. So that you can still get hold of TC members on IRC, we instituted a series of office hours on #openstack-tc: * 09:00 UTC on Tuesdays * 01:00 UTC on Wednesdays * 15:00 UTC on Thursdays For the coming week, I expect reports around the cross-community discussions that happened at KubeCon. Cheers, -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Blueprints moved out to Rocky
Hey folks, So I went through the list of blueprints and moved some that were either not updated or appeared to have a bunch of patches not in a mergable state. Please take some time to review the list of blueprints currently associated with Rocky[0] to see if your efforts have been moved. If you believe you're close to implementing the feature in the next week or two, let me know and we can move it back into Queens. If you think it will take an extended period of time (more than 2 weeks) to land but we need it in Queens, please submit an FFE. If you have an blueprint that is currently not in implemented in Queens[1], please make sure to update the blueprint status if possible. For the ones I left in due to the patches being in a decent state, please make sure those get merged in the next few weeks or we will need to push them out to Rocky. Thanks, -Alex [0] https://blueprints.launchpad.net/tripleo/rocky [1] https://blueprints.launchpad.net/tripleo/queens __ 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] [Release-job-failures][congress] Pre-release of openstack/congress failed
Ah sorry about that, Doug. And thank you for the pointer, Sean. I'm on it. On 12/8/17, 2:10 PM, "Sean McGinnis" wrote: >On Fri, Dec 08, 2017 at 04:06:15PM -0600, Doug Hellmann wrote: >> Excerpts from zuul's message of 2017-12-08 21:56:33 +: >> > Build failed. >> > >> > - release-openstack-python-without-pypi >>http://logs.openstack.org/08/080df7f0b147dc8290cc9ceb513ba5d8c1f8f295/pre >>-release/release-openstack-python-without-pypi/8c423e5/ : FAILURE in 5m >>53s >> > - announce-release announce-release : SKIPPED >> > >> >> This error looks like there is a bad file reference in the MANIFEST.in: >> >> error: can't copy 'etc/policy.json': doesn't exist or not a regular file >> ERROR: InvocationError: >> >>'/home/zuul/src/git.openstack.org/openstack/congress/.tox/venv/bin/python >> setup.py bdist_wheel' >> venv finish: runtests after 2.76 seconds > >I think this is needed to fix it. Some missing cleanup work from the >policy-in-code activity. > >https://review.openstack.org/#/c/526274/ > > >__ >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] Blueprints moved out to Rocky
Hi Alex, I don't see the tripleo ovs hardware offload feature. The spec was merge into queens [1], but for some reason the blueprint is not in approve state [2]. I has only 3 patches left: 1. https://review.openstack.org/#/c/507401/ has 2 +2 2. https://review.openstack.org/#/c/507100/ has 1 +2 3. https://review.openstack.org/#/c/518715/ I would appreciated if we can land all the patches to queens release. [1] - https://review.openstack.org/#/c/502313/ [2] - https://blueprints.launchpad.net/tripleo/+spec/tripleo-ovs-hw-offload > -Original Message- > From: Alex Schultz [mailto:aschu...@redhat.com] > Sent: Saturday, December 9, 2017 1:34 AM > To: OpenStack Development Mailing List (not for usage questions) > > Subject: [openstack-dev] [tripleo] Blueprints moved out to Rocky > > Hey folks, > > So I went through the list of blueprints and moved some that were either not > updated or appeared to have a bunch of patches not in a mergable state. > > Please take some time to review the list of blueprints currently associated > with Rocky[0] to see if your efforts have been moved. If you believe you're > close to implementing the feature in the next week or two, let me know and > we can move it back into Queens. If you think it will take an extended period > of time (more than 2 weeks) to land but we need it in Queens, please submit > an FFE. > > If you have an blueprint that is currently not in implemented in Queens[1], > please make sure to update the blueprint status if possible. For the ones I > left in due to the patches being in a decent state, please make sure those get > merged in the next few weeks or we will need to push them out to Rocky. > > Thanks, > -Alex > > > [0] > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu > eprints.launchpad.net%2Ftripleo%2Frocky&data=02%7C01%7Cmoshele%40 > mellanox.com%7C0abe7d8deef74a13d29508d53e945633%7Ca652971c7d2e4d > 9ba6a4d149256f461b%7C0%7C0%7C636483729194465277&sdata=xDwvHSmx > niqu6HN5FaQB2DTc6N8mRS879Ku1y4FDLss%3D&reserved=0 > [1] > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu > eprints.launchpad.net%2Ftripleo%2Fqueens&data=02%7C01%7Cmoshele%4 > 0mellanox.com%7C0abe7d8deef74a13d29508d53e945633%7Ca652971c7d2e4 > d9ba6a4d149256f461b%7C0%7C0%7C636483729194465277&sdata=v6v1yDjt1f > dc3FAILGsS2voCiMUmaLQGPwwxNtTzcso%3D&reserved=0 > > __ > > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev- > requ...@lists.openstack.org?subject:unsubscribe > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists. > openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack- > dev&data=02%7C01%7Cmoshele%40mellanox.com%7C0abe7d8deef74a13d2 > 9508d53e945633%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636 > 483729194465277&sdata=N%2B78nm8bMlSWsASO6uIX2mJlO1%2BX9VfTM2 > A3qUu6GUk%3D&reserved=0 __ 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] [upgrade] CI status and Current effort.
On Fri, Dec 8, 2017 at 11:42 AM, Emilien Macchi wrote: > On Fri, Dec 8, 2017 at 5:39 AM, Wesley Hayutin wrote: > [...] >> Sofer, can you estimate when the redhat-openstack gerrit repo will be >> dropped and the upstream >> openstac/tripleo-upgrades role used in it's place. I need to coordinate the >> CI team to work you and >> Jose Louis, however not using the upstream repo makes that difficult. > > When https://review.openstack.org/#/c/524141/ will be merged - we're > working on that. Alex cleanup the repo, today I rebased the patch and > added ansble-lint tests. When we have lint working, we'll probably > merge the patch. > From then, I don't see any blocker to use the upstream repo. OK, https://review.openstack.org/#/c/524141/ is now ready for review. I had to rebase https://review.openstack.org/#/c/524141/2..4/templates/create_registry_env.sh.j2 - please carefully review this one. Otherwise, we fixed lint and update the CI job, all looks good. Once we land it, we need to make sure we have all commits from the old repo, and then we need to kill the repo (following this commit: https://github.com/openstack/puppet-tuskar/commit/d54150a1ad61034cb73c6160fb57956d30f2b2d9). Then, use the new repo, and enjoy. Thanks, -- 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
[openstack-dev] [keystone] keystone client service_catalog is None
Hi all, I'm working on some code [1] that attempts to retrieve a endpoint from the service_catalog, but the service_catalog comes up None. Any suggestions on what I need to do differently to get a working service_catalog? Thanks very much! Python 2.7.12 (default, Nov 20 2017, 18:23:56) [GCC 5.4.0 20160609] on linux2 >>> from keystoneauth1 import session # Version 2.12.1 >>> from keystoneauth1.identity import v2 >>> import keystoneclient.v3.client as ksclient >>> auth = v2.Password(auth_url='http://127.0.0.1/identity', >>>username='admin', password='password', tenant_name='admin') >>> sess = session.Session(auth=auth) >>> keystone = ksclient.Client(session=sess) >>> print(keystone.service_catalog) None [1] https://review.openstack.org/#/c/526813/1/congress/datasources/monasca_driv er.py@94 __ 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
